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

[mendel.livejournal.com]

Oh, wait! There's a simpler problem here. You wrote

it has to be (a) an arithmetic type that (b) represents seconds since some epoch.

We've already seen that (a) is true in POSIX. As for (b), I think you've just confused the time_t type with time(2) or gettimeofday(2). Obviously a variable of type time_t can contain any value within range; it's just a variable.

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

[pne.livejournal.com]

I think you've just confused the time_t type with time(2) or gettimeofday(2). Obviously a variable of type time_t can contain any value within range; it's just a variable.

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?

What made me ask myself the question was an email which stated that "both Windows and POSIX define time_t to be in seconds" but that "As a side note, ISO C does not define the format of time_t, so an
implementation that used millisecond values would be ISO C compliant,
just not POSIX compliant."

Which you appear to have confirmed: POSIX says that one time_t "unit" is a second, but this is not part of the C standard itself -- which only says that I said (viz., that it's an arithmetic type used to represent time).

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.