On Mon, 26 Mar 2007 19:01:00 -0400, "Richard B. gilbert" <[EMAIL PROTECTED]> wrote:
>Robert Dodier wrote: >> On Mar 26, 12:50 pm, "Richard B. gilbert" <[EMAIL PROTECTED]> >> 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? _______________________________________________ questions mailing list [email protected] https://lists.ntp.isc.org/mailman/listinfo/questions
