Return to BSD News archive
Xref: sserve comp.protocols.time.ntp:3296 comp.os.386bsd.questions:7551 Newsgroups: comp.protocols.time.ntp,comp.os.386bsd.questions Path: sserve!newshost.anu.edu.au!munnari.oz.au!news.Hawaii.Edu!ames!sgiblab!swrinde!cs.utexas.edu!uunet!emba-news.uvm.edu!aix3.emba.uvm.edu!wollman From: wollman@aix3.emba.uvm.edu (Garrett Wollman) Subject: Re: FreeBSD and ntpdate behave strangely Message-ID: <1993Dec21.180003.20858@emba.uvm.edu> Sender: news@emba.uvm.edu Organization: University of Vermont, EMBA Computer Facility References: <1993Dec20.132523.14017@alw.nih.gov> Date: Tue, 21 Dec 1993 18:00:03 GMT Lines: 64 In article <1993Dec20.132523.14017@alw.nih.gov>, Chuck Bacon <crtb@helix.nih.gov> wrote: >However, while telnetted to this nearby host, I sunc. my wristwatch >there using `date`. Just to check, I then did `date` on my PC. >Behold, the PC was 14 sec. slow! It's not 14 seconds slow; both systems have the exact same idea of what time it is, in seconds since the Epoch. However, FreeBSD uses Arthur David Olson's timezone management code, which takes proper account of the leap seconds in the configuration for which we have set it up. Users of FreeBSD will notice the exact same discrepancy between their computer's battery-backed clock and the value reported by `date', because of the faulty computation of the UNIX time from the HMS time in the battery clock. It should be explained, for those not familiar with the code, that this does /not/ involve any sort of ``subtracting N seconds from the UNIX time'' etc. Rather, the timezone code assigns the following values: N = 23:59:59 on 30.6.-93 N + 1 = 23:59:60 on 30.6.-93 N + 2 = 00:00:00 on 1.7.-93 I would argue that this is the correct interpretation, even though POSIX got it completely wrong (it's not the only thing that POSIX got wrong). Since ISO 9899 (``ANSI C'') allows this sort of interpretation, this behavior is defensible from a standards point of view, and I would like to keep it as the default if at all possible. There are then two questions to be answered: 1) How can we tell NTP that the UNIX time on a FreeBSD system really is a count of /UTC/ seconds from 1 January 1970, and therefore prior leap seconds should be included in the calculation? (Do we have to break down the NTP time according to TAI rules, and then use our mktime() to calculate the correct, leap-second-cognizant value?) 2) When I implement the kernel PLL, how should this interact with the leap-second support? The example in the technical report (`fine.tar.Z') and in the NTP distribution handles leap seconds by advancing the clock /two/ seconds! This means that a user expecting to watch the leap second actually happen will be sorely disappointed, since the clock will get advanced right past the leap second, possibly throwing localtime() a second or two out of alignment (depending on whether or not the user has added the leap second listing to `/usr/src/share/zoneinfo/datfiles/leapseconds' and done a `make' in the appropriate directory. I have copied Mr. Timezone (Arthur Olson) and Mr. NTP (Dave Mills) as well as the FreeBSD-Hackers mailing-list, in the hope that some of the above can get together and figure out what the various bits of code expect of each other. -GAWollman (FreeBSD time maintainer) -- 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. uvm-gen!wollman | It is a bond more powerful than absence. We like people UVM disagrees. | who like Shashish. - Claude McKenzie + Florent Vollant