At 7:04 AM -0600 9/5/10, M. Warner Losh wrote:
In message: <17ed2322-170f-48c1-b6fb-0fa42d1e6...@batten.eu.org>
Ian Batten <i...@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
_______________________________________________
LEAPSECS mailing list
LEAPSECS@leapsecond.com
http://six.pairlist.net/mailman/listinfo/leapsecs
