![[personal profile]](https://www.dreamwidth.org/img/silk/identity/user.png){kind=small}
The things you learn: time_t
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).
no subject
NOTES This function is required by ANSI C. On a POSIX system, time_t is an arithmetic type, and one could just define #define difftime(t1,t0) (double)(t1 - t0) when the possible overflow in the subtraction is not a concern.So it sounds as though POSIX requires the unit of time_t to be seconds. The POSIX time_t is documented here (http://www.opengroup.org/onlinepubs/009695399/basedefs/sys/types.h.html). From that:time_t Used for time in seconds.So on a POSIX system you're guaranteed that time_t is measured in seconds. Now, granted, difftime gets rid of having to cast a time_t to a double, but I don't think existing code will break because of problems comparing two time_t's provided the system is POSIX compliant."Seconds since the Epoch" is defined here (http://www.opengroup.org/onlinepubs/009695399/basedefs/xbd_chap04.html#tag_04_14), though, and that confirms that you can't rely on the Epoch being 1970-01-01 00:00:00 UTC:
The relationship between the actual time of day and the current value for seconds since the Epoch is unspecified.no subject
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.
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.
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.
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.