NTP and POSIX Time in conflict?

Paul Eggert eggert at twinsun.com
Mon Dec 4 18:00:51 UTC 2000

> Date: Sun, 3 Dec 2000 21:17:13 -0500
> From: Joe Gwinn <joegwinn at mediaone.net>

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

Actually it's not at a constant offset.  Since 1972, the offset has
changed after each leap second.  Before that, the offset varied

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

No, actually, "true UTC" has this problem too, for time stamps near a
leap second.  The ITU standard allows you to represent UTC using
either a second-count or a broken-down time.  The body of the standard
refers to UTC as a second count in several places: it talks about
UT1-UTC, UT2-UTC, and UTC+DUT1, and all of these expressions assume
that UTC is a second count.  "Broken-down time" (what the standard
calls "marker dates") is defined only at the end, on the last page of
the standard.

The problem, of course, is that there is not a one-to-one relationship
between the two representations.  Second-counts are ambiguous near a
leap second; broken-down time stamps are not.  But this problem is
present in the ITU standard.  It's not a POSIX invention.

By the way, the latest version of the ITU standard is ITU-R TF.460-5.
However, the changes since 460-4 do not affect the points above.

> 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",

No it doesn't.  That claim is made nowhere in the tz sources, and (as
you have calculated) it is an incorrect claim.  Even in "right" mode,
the "tz" library says that the epoch is 1970-01-01 00:00:00 UTC.

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

Your calculations are correct, though your terminology is not quite
right, as leap seconds had not yet been invented at the moment of the
POSIX Epoch.  A better way to say it is that TAI-UTC was 8.000082
seconds at the point of the POSIX Epoch, i.e. that the POSIX epoch
1970-01-01 00:00:00.000000 UTC is equivalent to
1970-01-01 00:00:08.000082 TAI (exactly, by definition).

More information about the tz mailing list