TAI zone?

Guy Harris guy at alum.mit.edu
Thu Jun 30 03:31:20 UTC 2011


On Jun 29, 2011, at 7:57 PM, David Magda wrote:

> On Jun 29, 2011, at 22:46, Guy Harris wrote:
> 
>> So who was the person who wrote, in the current POSIX rationale:
> 
> A little of bit of history from a 2003 post to the "leapsec" listserv:
> 
> http://www.mail-archive.com/leapsecs@rom.usno.navy.mil/msg00109.html

Some of the cards "glued to the table" were glued there with Crazy Glue, emphasis on the "crazy":

> Initially there was a proposal to require the timestamps returned from system calls such as time(2) to yield the exact number of seconds since the time known as the Un*x epoch.  This calculation included the known leap seconds at the time.
> 
> Unfortunately at the time nearly all Un*x implementations did NOT take seconds into account.  For example, there were a non-trivial number of file system i-nodes and dump tapes that used a "trivial seconds since the Epoch" calculation.

I'm not sure what "calculations" are being discussed here.

The only "calculation" involved in time() values, stat() time stamps, etc. is counting up by 1 every second; that requires no knowledge of leap seconds.  *Not* counting up during leap seconds requires knowledge of leap seconds.

The calculations involved in converting those values to labels (e.g., in localtime(), gmtime(), and mktime()) would require knowledge of leap seconds if it's to produce correct UTC labels in gmtime() (and, presumably, shifted labels in localtime()).

Life is a lot more confusing if you think "time stamps" are {date}/hour/minute/second labels rather than "counts of seconds that have elapsed since some particular instant of time in the past".  Fortunately, time() values, stat() time stamps, etc. are the latter rather than the former.

Now, maybe some clock hardware used by UN*X systems works with {date}/hour/minute/second labels, so that you have to convert from that to UN*X time either when the system boots or once per timer interrupt.  I doubt that hardware knows about leap seconds, however; if not, it really amounts to a timer that ticks once per second, but that does some weird arithmetic on the result of that counter to produce labels, so it can fairly easily be converted back to "seconds since some arbitrary point in the past" if, whenever you set it, you set it with a label calculated in the same fashion.

> Distributing leap second tables and requiring hosts to be "on-line" to receive them in those days (when UUCP over slow baud modems was common) was not considered realistic.  It was felt expect vendors and/or system administrators to maintain a complete leap second table (including leap seconds announced in advance) was also considered unrealistic.

Actually, not too long into the POSIX discussions, somebody came up with a system that involved distributing tables of time zone offsets, including times at which the offsets changed due to daylight savings time coming into effect and going out of effect, and even provided an implementation of the UN*X time conversion APIs that used those tables, and at least one common UN*X of the time shipped with them in its 4.0 release.  I think those people later added in support for leap seconds in those tables - which changed more often due to time zone changes due to various local and national government actions (one of which provoked the creation of the system in question; thank you, Clorox, for wanting to sell more Kingsford charcoal briquets :-)) than due to leap seconds being introduced.

Perhaps the real problem was with the people with the unfortunate attitude:

> "What matters to me is just that POSIX systems produce the same ctime(3) string (i.e., Wed Jun 30 21:49:08 1993\n") when given the same time(2) time-stamp."

If they could've been disregarded, we could have allowed the Olson implementation, complete with leap seconds in the database, to conform, and let the systems that didn't use the Olson implementation just stay stuck.

(Perhaps having to deal with non-UN*X systems, that would have to convert between their own internal clock values, represented however they might be, and time_t, didn't help, either.  However, I suspect many of those systems had, at the time, clocks that, in effect, ticked along once per second, either as counters or as TAI-ish labels.)



More information about the tz mailing list