NTP and POSIX Time in conflict?

[Joe Gwinn]

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 
and program.

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 
what problem?

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 
seconds.

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.

Joe