Definition of time_t changed from signed to unsigned...

[Bradley White]

Susan (Chris?) Richards asked:
> As I've been going through the TZ code, I've seen the leap correction code. 
> 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.

The adjustment for leap seconds is made when converting a time_t to
a struct tm.

> So my understanding is:-
> UTC   - includes leap seconds

An ado "right" time_t includes leap seconds (i.e., it keeps ticking
through leap events).

> POSIX - no leap seconds included.

A POSIX time_t uses 86400-second days (i.e., the system time must be
adjusted during leap events).

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

If you are running in "right" mode, time(0) returns a "right" time_t.
"posix" mode, of course, results in a POSIX time_t.  Given that NTP uses
POSIX-like timestamps, a call to time2posix() needs to be added to NTP
in order for it to correctly synchronize an ado "right" system (after
which it can also ignore leap warnings).

> 2) The date & time displayed using "date" also takes into account leap 
>    seconds.

"date" always displays the civil time.  A non-"right" system will show
a discontinuity over a leap event, however.

> 3) If I want to report POSIX time, I need to call time2posix().

Correct ... time2posix() always returns a POSIX time_t whether you are
running in "right" mode or not.

Bradley