leap seconds [forwarded with permission from wollman@uvm-gen.emba.uvm.edu]
From wollman@uvm-gen.EMBA.UVM.EDU Sun Feb 6 17:45:52 1994 Return-Path: <wollman@uvm-gen.EMBA.UVM.EDU> Received: from bajoran.emba.uvm.edu by elsie.nci.nih.gov (4.1/SMI-4.1) id AA18437; Sun, 6 Feb 94 17:45:51 EST Received: by bajoran.emba.uvm.edu id AA18471 (5.65/6.05); Sun, 6 Feb 94 17:45:50 -0500 Date: Sun, 6 Feb 94 17:45:50 -0500 From: wollman@uvm-gen.EMBA.UVM.EDU Message-Id: <9402062245.AA18471@bajoran.emba.uvm.edu> To: ado@elsie.nci.nih.gov Subject: Re: timezone servers Newsgroups: comp.protocols.time.ntp In-Reply-To: <1994Feb4.234532.26832@alw.nih.gov> References: <199402020109.AA01671@ni.umd.edu> Organization: University of Vermont, EMBA Computer Facility
...According to the bulletins that I've seen, |TAI-UTC| is about 28 seconds now. However, the leapseconds file only lists 19 steps. This is probably due to the fact that the first step was 10 seconds, not just 1. Is there an easy way to fix this, so my users who use NTP don't complain about their clocks being nine seconds off?
-GAWollman -- Garrett A. Wollman | Shashish is simple, it's discreet, it's brief. ... wollman@emba.uvm.edu | Shashish is the bonding of hearts in spite of distance. NB: Address soon to | It is a bond more powerful than absence. We like people be changed. | who like Shashish. - Claude McKenzie + Florent Vollant
Date: Sun, 6 Feb 94 17:45:50 -0500 From: wollman@uvm-gen.EMBA.UVM.EDU ...According to the bulletins that I've seen, |TAI-UTC| is about 28 seconds now. However, the leapseconds file only lists 19 steps. This is probably due to the fact that the first step was 10 seconds, not just 1. Is there an easy way to fix this, so my users who use NTP don't complain about their clocks being nine seconds off? I'm not sure what you mean by ``fix''. Let me try to review the problem, perhaps repeating information that you already know. Posix defines the time origin to be 1970-01-01 00:00:00 UTC. But there's a problem with this definition: there is no such time, because UTC didn't exist then! UTC was not established until two years later (1972-01-01 00:00:00). UTC obeys two constraints: (1) |UTC-TAI| is an integer, (2) |UT1-UTC| < 0.9 s. TAI is International Atomic Time, our best approximation to ``real'' time. UT1 is astronomical time, our best approximation to Earth's rotation angle; it was the basis for civil time between 1956 and 1972. When UTC was established in 1972, UTC-TAI was set to be exactly 10 s. This explains why UTC-TAI will be 29 s after 1994-06-30, even though the leapseconds file lists only 19 seconds inserted by then. Why was UTC-TAI initially 10 s and not zero? Because UTC is designed to track UT1 within 0.9 s, and UT1-TAI was approximately 10 s at the time UTC was established. And _this_ is because TAI was set approximately equal to UT1 on 1958-01-01, and the two scales had diverged by 10 s in 1970. Had UTC existed on 1970-01-01 under the current rules, it would have differed from TAI by either 7 or 8 s. The ambiguity is because of the slop in UTC's constraint (2). In practice, this ambiguity is resolved by a committee of the International Earth Rotation Service, but that won't help us for times before 1972. So, to get back to the original question, how should you fix this? I see three possible fixes: A. Leave the leapseconds file alone, and pretend that civil time equaled TAI + 10 s before 1972. Add a 10 s correction to the code that converts between the tz package's times and NTP. This introduces an error of about 2 or 3 s for times around 1970. B. Invent some leap seconds for the period between 1970 and 1972, as if UTC had been in effect then. This lies about UTC but repairs the 2 or 3 s error. The conversion correction would be correspondingly reduced, to 7 or 8 s. C. Invent some leap seconds for the period between 1955-07-01 and 1972. This is the same as (2) but reduces errors for old times. We can't go back before 1955-07-01 because atomic time didn't exist before then. A problem with (C) is that some hosts don't allow negative time_t values. (A) is easiest and in a sense is the most honest, but it has one major problem: it leaves us 2 or 3 s away from our goal of having time_t values that represent ``the number of seconds since 1970-01-01 00:00:00 GMT'', the way Unix was originally intended.
<<On 7 Feb 1994 13:49:18 -0800, eggert@twinsun.com (Paul Eggert) said:
B. Invent some leap seconds for the period between 1970 and 1972, as if UTC had been in effect then. This lies about UTC but repairs the 2 or 3 s error. The conversion correction would be correspondingly reduced, to 7 or 8 s.
This is the preferred solution for our (FreeBSD) users, I think. Currently, we have a situation where there is a 17-second discrepancy between the time as displayed certain other NTP-running systems, as compared to ours, which quantity really doesn't suggest anything to someone trying to figure out what's going on. If we can arrange things so that the discrepancy works out ot be exactly |TAI-UTC|, then time-savvy users can then say, ``Oh! Obviously, (system X) doesn't handle leap seconds!'' and then stop sending in bug reports about it. Then all I have to do is figure out what NTP expects the kernel time to do around leap seconds, and we should be set! -GAWollman -- Garrett A. Wollman | Shashish is simple, it's discreet, it's brief. ... wollman@emba.uvm.edu | Shashish is the bonding of hearts in spite of distance. NB: Address soon to | It is a bond more powerful than absence. We like people be changed. | who like Shashish. - Claude McKenzie + Florent Vollant
[Thanks for the UTC/UT1/TAI summary, Paul.] In <9402072223.AA23255@bajoran.emba.uvm.edu>, wollman@emba.uvm.edu writes:
Currently, we have a situation where there is a 17-second discrepancy between the time as displayed certain other NTP-running systems, as compared to ours, which quantity really doesn't suggest anything to someone trying to figure out what's going on. If we can arrange things so that the discrepancy works out ot be exactly |TAI-UTC|, then time-savvy users can then say, ``Oh! Obviously, (system X) doesn't handle leap seconds!'' and then stop sending in bug reports about it.
Then all I have to do is figure out what NTP expects the kernel time to do around leap seconds, and we should be set!
Any system that runs with ``REDO=right_*'', and which therefore wants to continue to tick normally over leap seconds, needs to do a little bit of work to generate NTP-style timestamps. That is, NTP-style timestamps are discontinuous over leaps, while ``REDO=right_*'' time_t's are continuous. Recent incantations of the `tz' package provide the time2posix() function to help in mapping between these two formats. For example, in the (old, version-1) NTP code, you need to change ... stampp->int_part = htonl(tvp->tv_sec + JAN_1970); to stampp->int_part = htonl(time2posix(tvp->tv_sec) + JAN_1970); I haven't looked at the (new, version-3) XNTP code, but I imagine the change needed there is just as trivial. After that, you will chime NTP harmoniously with the rest of the world, *and*, you will sail smoothly through leap events without the jitter or confusion suffered by your NTP peers. Bradley
participants (4)
-
ado -
Bradley White -
eggert@twinsun.com -
wollman@uvm-gen.EMBA.UVM.EDU