Definition of time_t changed from signed to unsigned...
bww at acm.org
Thu Aug 19 15:15:40 UTC 2004
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
"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.
More information about the tz