The things you learn: time_t

[pne]

I thought that while time_t need not be an unsigned 32-bit integer (it could also be a 64-bit integer, for example, or even a double-precision floating-point number), it has to be (a) an arithmetic type that (b) represents seconds since some epoch.

Apparently, only (a) is correct; AFAICT, the standard does not make any requirement about the encoding, not even that one "unit" is a second, only that (time_t)-1 has a special meaning. So it could be, for example, a 64-bit count of milliseconds since some epoch. Subtracting two time_t values and expecting the result to make any specific sense is, therefore, unportable; you have to use difftime() for that (which is documented to return a count of seconds as a double-precision floating-point number, no matter what "time_t" is encoded like).

Comments

Re: C vs POSIX, or, the good thing about standards is that there are so many to choose from.

[mendel.livejournal.com]

No, I did mean time_t in the context of a return value of time(2) -- as in, given two return values of time(2) at different periods in time, can you subtract them and obtain a meaningful answer?

Right, you mean the return value of time(2), and you don't mean time_t. If time(2) returned double your question would be exactly the same.

Re: C vs POSIX, or, the good thing about standards is that there are so many to choose from.

[pne.livejournal.com]

Right, you mean the return value of time(2), and you don't mean time_t. If time(2) returned double your question would be exactly the same.

Essentially, yes. Whatever semi-opaque token time(3) and mktime(3) and timegm(3) and friends return and that can be passed to ctime(3) and localtime(3) and friends. Which happens to be time_t, and which is typically the only way this type is used.

The question was how opaque this shared token is: in POSIX, it's fairly transparent (number of seconds), but the C standard itself makes no such guarantee.