[ntp:questions] ntpd sets clock to the year 1939

Per Hedeland per at hedeland.org
Tue Mar 27 23:38:12 UTC 2007

In article
<4B73D9EBE2327E40B4D69822D7C45802068D0880 at sjmail1.symmetricom.com>
GDowd at symmetricom.com (Greg Dowd) writes:
>The problem is not so much that NTP has a limitation on bits and an
>overflow condition.  This is always the case.  Dave was able to modify
>the code slightly, by switching to a double earlier, and change the
>window from 34 years to 68 years.  This allowed him to keep that least
>significant bit included in the calculation.

I agree with this basic principle (and the rest of what you wrote), but
I believe that your numbers are off by a factor of two. NTP timestamps
use a 32-bit unsigned quantity for the seconds, with the base year 1900
- this means that the window should be 136 years, and that any point in
time in the range ~ 1900..2036 can be unambiguously represented. I
believe that the fix was to change the effective window from 68 years
(due to what must be considered a bug) to the "proper" 136 years. And I
wonder if this fix is in the version the OP used (not mentioned as far
as I can see).

Assuming a window of 68 years (for whatever reason), timestamps in the
ranges 1900..1968 and 1968..2036 can not be distinguished from each
other, and some assumption has to be made if the current year is 1970
and the time stamp supposedly representing "correct" time can be
interpreted as either 1939 or 2007 - 1939 is definitely closer, and thus
a reasonable choice absent other "additional logic" (such as time of
compilation of the binary that has been mentioned - or in this case even
a hardwired constant in the code). Or put another way, ntpd assumes a
window that is symmetric around the current system time.

OK, I had to test it myself, especially after having been chastised by
Steve in the orphan thread.:-) With ntpd 4.2.0-a (what ships with
FreeBSD 5.4), I saw exactly the same behaviour as the OP - I set the
date to 1970, and ntpd -g hapily set it back to 1939. However ntpd
4.2.4p0 did the right thing:

Jan  1 00:00:26 pelle ntpd[21059]: ntpd 4.2.4p0 at 1.1472-o Tue Mar 27 22:43:41 UTC
 2007 (1)
Mar 28 00:45:25 pelle ntpd[21060]: time reset +1175039090.075990 s

- and in fact it continues to do the right thing if the original date is
as far back as 1940 (too bad my syslogd doesn't show the year:-):

Jan  1 00:00:09 pelle ntpd[21110]: ntpd 4.2.4p0 at 1.1472-o Tue Mar 27 22:43:41 UTC
 2007 (1)
Mar 28 00:54:34 pelle ntpd[21111]: time reset +2121810856.014114 s

- whereas with the original date in 1938, the 136-year window comes into
play, and it decides to interpret the received timestamp as 1871 (67
years off) rather than 2007 (69 years off):

Jan  1 00:00:07 pelle ntpd[21102]: ntpd 4.2.4p0 at 1.1472-o Tue Mar 27 22:43:41 UTC
 2007 (1)
Mar 28 00:52:17 pelle ntpd[21103]: time reset -2110084575.114568 s

- however at this point the Unix internal time representation comes into
play, and we end up at 2007 despite ntpd's efforts to the contrary.:-)

And just to hopefully dispel some myths about *that*, i.e. Unix/POSIX
time representation: First of all it really has nothing to do with NTP
timestamps, but obviously ntpd needs to convert between the two. And it
(currently) uses a 32-bit *signed* quantity for the seconds, with the
value 0 in Jan 1970. This means that it too has a 136-year window, and a
range of ~ 1902..2038 - i.e. it doesn't "start" in 1970. There is
(currently) no issue with deciding what time a given value represents
though - the window is locked down to that single range.

I.e. bottom line to the OP: Upgrade ntpd and you should be fine until
2038. But at that point you will have to do something unless "additional
logic" has been put into ntpd - Unix time will likely be a 64-bit signed
quantity by then, but still with 0 in 1970...

--Per Hedeland
per at hedeland.org

More information about the questions mailing list