[LEAPSECS] Coming of age in the solar system

Joe Gwinn joegwinn at comcast.net
Sun Sep 5 10:45:23 EDT 2010


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


More information about the LEAPSECS mailing list