[LEAPSECS] Coming of age in the solar system

[Joe Gwinn]

At 7:04 AM -0600 9/5/10, M. Warner Losh wrote:

>In message: <17ED2322-170F-48C1-B6FB-0FA42D1E66FB at batten.eu.org>

>             Ian Batten <igb at batten.eu.org> writes:

>: Does Posix say much about how time is handled, beyond providing

>: interfaces to get and set it and to mess about with representations?

>

>Yes.

>

>time_t is explicitly UTC, but without leap seconds (so not really

>UTC).  Every single day is 86400 seconds.  Leap seconds do not exist

>(and are dismissed as unimportant in the rational).


No, time_t is *not* UTC, as leap seconds are specifically excluded.

Of the standard timescales, POSIX Time is in theory closest to TAI, 
being TAI plus an unknown but usually constant (or slowly varying) 
offset.

In practice, POSIX Time is usually whatever the governing GPS 
receiver and NTP say it is.



>There's no

>definition of "correct" for how time ticks during a leap second (four

>exist: freeze the clock to the application during the leap second,

>slew time at an unnatural rate, repeat the last second of the day,

>repeat the first second of the day).  There's no way to unambiguously

>encode a leap second.


All true, because POSIX Time is its own timescale, and is not UTC, 
even though the timescale origin (time zero) of POSIX is defined in 
terms of UTC.

As for the handling of leap seconds in practice, it's whatever the 
local NTP says it is.  Most seem to repeat the last second.



>There's no interface provided to know how many

>PPS pulses there have been between two time_t's.  There's problems

>with some APIs that specify absolute time (or even relative time):

>across a leap second do you fire on the first or second instance of

>that time (assuming a repeat the second), do you count leap second

>time in the relative timeouts (were they done to wakeup on-time, or in

>a precise interval from now).  If slewing the time, do you accept

>errors introduced by that frequency error?


In practice, you do accept the error during slewing, for want of a 
better alternative.



>The root of the problem is that all the "clever" solutions to these

>problems break somebody.  Time going backwards has burned databses, as

>well as cautious programmers who check to make sure time isn't going

>backwards.  Stopped time works great for some applications, but gets

>in the way of many network protocols (video and audio really hate it).

>Slewing time also causes problems for audio and video playback (but

>repeated time doesn't).  There's no universally good "paper over the

>problem" solution here.


The core issue is that the requirements on a "POSIX Clock" depend 
more on the reliable ordering of events in a platform than accurate 
time per se.

POSIX allows the definition of any number of clocks by the operating 
system implementor.  I don't know if anyone has ever taken advantage 
of this freedom, but I wouldn't necessarily know either.



>Leap seconds do not exist in a POSIX world.  Sure, it works for most

>people, most of the time.  But it makes it very difficult to get leap

>seconds right.  That's one of those half-assed solutions that I keep

>mentioning that's getting in the way of a proper solution.  There's so

>many details to plow through, and so many ambiguities to overcome that

>its very hard to deploy a system that works 100%: You have to pick and

>choose your poisons, which limits your flexibility in merging new

>technologies into the system which might require a different mix of

>poisons.

>

>So POSIX won't save you: it is part of the problem.


True enough, but the history is instructive:

I have tried to rationalize POSIX timekeeping at least twice, but the 
time folk always descended into a nasty civil war, and the POSIX folk 
all scattered in incomprehension -- what *are* they talking about so 
angrily?

What resulted was the clear definition of POSIX time in the 200x 
standards, a definition that specifically excludes leap seconds by 
saying that each and every day in POSIX is exactly 86,400 seconds 
long, which had the intended effect of excluding UTC.

This was the POSIX folks' way of telling the time folk to please 
settle their nasty little war elsewhere.

For more information:  There are some long threads about the battles 
in the TimeNuts and LeapSec archives, with pointers into the earlier 
POSIX battles.  And rumours of the battles of the 1980s while the 
first version of the POSIX standard was being developed.  There is 
nothing new under the Sun.


Joe Gwinn

Chair, POSIX Realtime
Vice Chair, POSIX SEC