[LEAPSECS] Coming of age in the solar system

[M. Warner Losh]

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).  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.  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?

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.

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.

Warner