NTP and POSIX Time in conflict?
joegwinn at mediaone.net
Mon Dec 4 02:17:13 UTC 2000
First, let me introduce myself. I am the Chair of the Realtime part
of the POSIX standards committee, the Vice Chair of all POSIX, and
only slightly time-obsessed. I have been trying to straighten POSIX
time issues out, but hasten to add that the larger POSIX community
does not really care that much about accurate time, so it may take
some persuading to make any changes.
The current POSIX standard (IEEE Std 1003.1-1996) is very confusing
and perhaps confused in its definition of time and time-related
functions. Their intent appears to have been to dodge the whole
issue of leap seconds (because isolated systems cannot know of leap
seconds), to ensure that such things as file modification dates were
causal (to the resolution of the clock), and to be simple to define
The fundamental clock of POSIX is "Seconds Since the Epoch",
essentially a count (time_t) of SI Seconds elapsed since the Epoch
(00:00:00 UTC 1 January 1970 AD), to which leap seconds are not
applied. I call this clock "POSIX Time", and observe that it
parallels TAI, albeit at a constant offset.
"Broken-down time" in POSIX resembles UTC, but as leap seconds are
not applied,is not in fact UTC. The fundamental problem with POSIX
here is that the functions specified for conversion between POSIX
Time and broken-down time fail if leap seconds are involved, in
particular there are time values in one form that cannot be expressed
in the other form. True UTC, as defined in ITU TR 460-4, does not
share this problem, so posix is broken here.
The above is background. Now some questions.
1. I have heard it claimed that the broken-ness of posix time
prevented NTP from handling leap seconds correctly. Would you care
to comment on this? Specifically, what specific brokenness causes
2. Arthur David Olson's library "tz" defines the POSIX Epoch as
"1970-01-01 00:00:10 TAI", which is to say that POSIX Time differs
from TAI by ten seconds. However, when I compute the difference
using the USNO table of leapseconds, I get 8.000082 seconds, or very
close to eight seconds, this being the number of leap seconds in UTC
as of the POSIX Epoch. Why the difference? Ten seconds is the value
when leap seconds were first applied, just before 1 January 1972, but
is too large for 1 Jan 1970, and so it's tempting to simply define
POSIX Time as offset from TAI by exactly eight whole seconds. Being
off by 82 microseconds seems far less of a sin than being off by two
Arthur David Olson recalls in an email that the intent was that if
time_t is zero, then tm_min and tm_sec will also be zero, and the
non-leapsecond and leapsecond scales will coincide at the Epoch, but
diverge thereafter. One consequebce of this choice is the added
constant two-second offset. Do you know of any added rationales?
The issue here is which offset should POSIX choose, and why.
More information about the tz