FW: Definition of time_t changed from signed to unsigned...
eggert at CS.UCLA.EDU
Thu Aug 19 18:18:28 UTC 2004
> From: Susan Richards [mailto:cj_richards at hotmail.com]
> Sent: Wednesday, August 18, 2004 12:58 PM
> It appears that the adjustment for leap seconds is made when converting the
> UTC system time (which includes leap seconds) to POSIX (which does not) or
> visa versa.
> So my understanding is:-
> UTC - includes leap seconds
> POSIX - no leap seconds included.
> Is this correct?
Not really, though the issue is not as clear as it should be.
When you're talking about time as a count of seconds since an epoch,
POSIX time omits completed leap seconds. UTC is normally thought of
as a broken-down time like "1998-12-31 23:59:60" (the last leap
second), but if you want to think of it as a count of seconds, then
it's equivalent to POSIX time. See, for example, the official
announcement of the latest leap second:
This announcement makes it clear that UTC-TAI was -31 seconds through
the last leap second, and -32 seconds thereafter, and this is exactly
how POSIX time behaves.
So it would be more accurate for you to write:
TAI - includes leap seconds
POSIX - no leap seconds included
> If my system is maintaining UTC (as set by some NTP server), and running the
> timezone database code, then are my following assumptions correct:
> 1) The result of calling time(0) is UTC (as maintained by NTP) and does
> include leap seconds.
Typically NTP maintains POSIX time, not TAI. I don't know if you can
configure it to maintain TAI.
> 2) The date & time displayed using "date" also takes into account leap
If you've configured your system so that time_t counts TAI seconds
instead of POSIX/UTC seconds, and if you're using the Olson code with
a "right" database, then yes, the date & time code does that.
> 3) If I want to report POSIX time, I need to call time2posix().
Yes, that sounds right.
More information about the tz