NTP and POSIX Time in conflict?
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
Joe Gwinn wrote:
"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 severely practical problem is that clocks on POSIX systems are typically set from UTC (either directly, or via NTP) and are then expected to tick TAI time units thereafter. This produces a whole set of scales each 1 sec off from its neighbor. Even systems which adjust their local clocks to take leap seconds into account typically do so only for a range of leap seconds, roughly, those which occurred before the machine was installed. -- There is / one art || John Cowan <jcowan@reutershealth.com> no more / no less || http://www.reutershealth.com to do / all things || http://www.ccil.org/~cowan with art- / lessness \\ -- Piet Hein
John, At 12:12 PM -0500 00/12/4, John Cowan wrote:
Joe Gwinn wrote:
"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 severely practical problem is that clocks on POSIX systems are typically set from UTC (either directly, or via NTP) and are then expected to tick TAI time units thereafter. This produces a whole set of scales each 1 sec off from its neighbor.
Yes. Probably won't soon change either.
Even systems which adjust their local clocks to take leap seconds into account typically do so only for a range of leap seconds, roughly, those which occurred before the machine was installed.
That is the current issue for sure; what's needed is the schedule of past and near future leapseconds. This cannot be required for POSIX, which must support isolated systems, but it should be possibel for POSIX systems to use lepasecond information correctly. Joe
Some operating systems use local time as their basic clock. Novice programmers often tell me that this is a good thing. I always find it amusing to compare their arguments to the anti-leap-second arguments: Clocks are local time Clocks are non-leap-second counters -------------------------------------------------------------------- Computer clocks are set by Computer clocks are set by humans, who use local time. NTP, which counts non-leap seconds. I don't know the time zone. I don't know the UTC-TAI difference. Who cares about occasional Who cares about occasional errors in time subtraction? errors in time subtraction? Governments change time zones. IERS changes the leap-second table. Keeping up to date is painful. Keeping up to date is painful. I just signed a contract that I just signed a contract that specifies a future local time. specifies a future time in UTC. How do I represent that time? How do I represent that time? An isolated system can't learn An isolated system can't learn about time-zone changes. about new leap seconds. The unfortunate reality is that an isolated system can't maintain an accurate local-time clock. How do we react to this? Do we screw up the semantics of localtime(), saying that it's just fine for localtime() to ignore changes in time zones and in the leap-second table? Or do we maintain our standards for the semantics of localtime(), and acknowledge that isolated systems can't support it properly? ---Dan
Date: Sun, 3 Dec 2000 21:17:13 -0500 From: Joe Gwinn <joegwinn@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 continuously.
"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).
participants (4)
-
D. J. Bernstein -
Joe Gwinn -
John Cowan -
Paul Eggert