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

Greg Dowd GDowd at symmetricom.com
Tue Mar 27 16:12:56 UTC 2007

Message: 8
Date: Tue, 27 Mar 2007 07:49:36 GMT
From: "David J Taylor"
	<david-taylor at blueyonder.not-this-bit.nor-this-part.co.uk>
Subject: Re: [ntp:questions] ntpd sets clock to the year 1939
To: questions at lists.ntp.isc.org
Message-ID: <k04Oh.499$NK2.358 at text.news.blueyonder.co.uk>

Richard B. gilbert wrote:
> It's hardly ever a problem since most systems have a hardware clock of

> some sort that can supply a reasonable starting point.  In 2007, I 
> don't think that 1970-is a reasonable starting point.

Whilst I have some sympathy for that viewpoint, NTP should not today
have that 30-year limitation (delighted to hear it is being extended).

It is not a defect of the OS that it allows its real-time clock to be
set /before/ the base time - 1970?


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.  Never know when those
picoseconds are going to count!

The real problem is, and we've debated this before, that ntp happily
sets the clock to the incorrect time and clears the unsynchronized bits
and reports good health to anyone listening.  According to the integer
math, this isn't incorrect time, it simply belongs in another epoch (or
window).  If you want to handle this case, it requires additional logic.
The debate then switches to whether it is necessary to force every
implementation to check whether or not the offset is a large negative
value before applying and spit an error if -g isn't set or something
along those lines.  Because this is most often an issue for embedded
systems developers, the perception was that these developers should
solve their own problem by initializing the clock to a known value.  

We've all pretty much done that but I still debate whether or not this
is the correct approach.  The system which are really tripped up by this
are going to be unattended unix or windoze machines initializing to
default clock values.  Until a process is in place to correct this, you
would typically expect ntp (the network time protocol) to set the clock
correctly, even if it had to iterate a few times.  

Dave had talked about having ntp log an error, and/or die, if it is
invoked on a system where the time difference between the const compile
time and the system time exceeds some window.  This doesn't help
embedded systems guys but it might help system operators trying to debug
why ntp can't set time correctly.  I don't believe this was ever added
to the codebase.

Greg Dowd
gdowd at symmetricom dot com (antispam format)
Symmetricom, Inc. 
"The current implementation is non-obvious and may need to be improved."

More information about the questions mailing list