FW: Definition of time_t changed from signed to unsigned...

[Paul Eggert]

> 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:

<http://hpiers.obspm.fr/eoppc/bul/bulc/bulletinc.16>

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 
> seconds.

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.