Philip Newton <[EMAIL PROTECTED]> writes:
> You have another assumption up there: that time_t == signed long (since
> you're printing it with %ld) with a resolution of seconds (since you say
> "%ld seconds"). ISO/IEC 9899:1999 (draft C standard, the only C
> standard-y thing I have around) says that time_t is an "arithmetic type"
> (OK, so you're allowed to subtract one from another) "capable of
> representing time", and that "the range and precision representable in
> clock_t and time_t are implementation-defined".
Don't pay any attention to anything the draft C standard says about time;
there were some major changes that were backed out of the final standard,
so that section of the draft is very misleading.
The final ISO standard, section 7.23.2.4 paragraph 2, says:
2 The time function determines the current calendar time. The encoding of
the value is unspecified.
I don't see anywhere in the final specification where time_t is guaranteed
to be an arithmetic type, so you *aren't* guaranteed that you can perform
math operations on them.
POSIX does provide this guarantee, along with a few others, but in
strictly conforming C, the only thing you can do with a time_t is pass it
to one of the conversion functions or use difftime to compare it to
another one.
> So subtracting them may not give you seconds since any epoch (that's
> what the difftime() is for; it explicitly gives you seconds of
> difference, as a double), and even if you knew it did, there's no
> guarantee that %ld is the correct format to print it out. Might as well
> be %llu or %d as %ld.
> Maybe POSIX makes more guarantees.
I'm pretty sure POSIX requires it to be an arithmetic type, as well as
requiring that the epoch be 1970-01-01T00:00:00+0000, but I'm pretty sure
it doesn't specify the size (nor should it).
The C99 way of printing out time_t *if* you're guaranteed it's an
arithmetic type is:
#include <inttypes.h>
time_t now;
printf(PRIdMAX "\n", (intmax_t) now);
--
Russ Allbery ([EMAIL PROTECTED]) <http://www.eyrie.org/~eagle/>
