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

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
participants (1)
-
Bradley White