[ntp:questions] ntpd sets clock to the year 1939
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>
>>>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.
>> 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