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

Marc Brett usenet at fordson.demon.co.uk
Tue Mar 27 16:09:46 UTC 2007

On Tue, 27 Mar 2007 11:04:02 -0400, "Richard B. gilbert"
<rgilbert88 at comcast.net> wrote:

>Marc Brett wrote:
>> On Mon, 26 Mar 2007 19:01:00 -0400, "Richard B. gilbert"
>> <rgilbert88 at comcast.net> wrote: 
>>>Robert Dodier wrote:
>>>>On Mar 26, 12:50 pm, "Richard B. gilbert" <rgilber... at comcast.net>
>>>>>I believe that there is a limit to the date/time range that ntpd can
>>>>>handle and that it's something like 36 years.  Try setting the date
>>>>>manually to something a little closer to being current.  If it's off by
>>>>>less than 36 years, I think ntpd will handle it correctly.  A startup
>>>>>script that set the date to a reasonable approximation; e.g. 2007 would
>>>>>probably solve your problem and work for the next 36 years or so.
>>>>Yes! That's it. I set the date by hand to Jan 1, 2007, and then ntpd
>>>>able to handle the rest. It seems odd to me that ntpd gets confused by
>>>>too large a time difference, but oh well, it's OK the way it is.
>>>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.
>> "Be liberal in what you accept, conservative in what you send."
>> We may not think that 1970 is a reasonable starting point, but these systems
>> exist today and ntpd should deal gracefully with them.  In fact, a POSIX time of
>> 0 is not exactly an unreasonable starting date for a system with no hardware
>> clock and no DHCP-specified NTP server.
>> It's unfortunate that applications (especially an application dedicated to
>> keeping the correct time, fer cryin out loud) fall over when faced with such a
>> time value, but whose fault is that?
>The opposite argument would be that it's not reasonable for ntpd to make 
>a "leap of faith" and jump the time by 36 years!

But 26 years, say, is perfectly reasonable?

>Ntpd is designed to 
>consider a clock that's off by 1024 seconds or more as a situation it is 
>not equipped to handle.  Ntpd is behaving as it's designed and 
>documented to behave.

But it isn't.  The "ntpd -g" documentation says:

Normally, ntpd exits with a message to the system log if the offset exceeds the
panic threshold, which is 1000 s by default. This option allows the time to be
set to any value without restriction; however, this can happen only once. 

"Without restriction" means, to me, that time jumps of 26 years, 36 years, or 46
years are all perfectly fine.

>The source is available and anyone with the necessary skills can modify 
>it to handle special cases like this.  Anyone lacking the necessary 
>skills can pay someone with the skills to do the work.

Maybe the gumstix folk can be persuaded...

More information about the questions mailing list