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

Marc Brett usenet at fordson.demon.co.uk
Tue Mar 27 13:39:14 UTC 2007


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>
>> wrote:
>> 
>> 
>>>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
>> was
>> 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.
>> 
>> Thanks for your help,
>> Robert Dodier
>> 
>
>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?





More information about the questions mailing list