[ntp:questions] Re: ??-Ntp sets time to year 2036
swidmer at widmertime.com
Thu Sep 18 04:28:34 UTC 2003
Thank you for your response, it has been a while since we talked, almost 4
years. Let me thank you again for all your help back then and now with the
Why might a device which is not recieving a NTP broadcast due to a network
outage suddenly show this behaviour. I would think the device would just
continue to mark time in its own fashion until another broadcast is
recieved..also I would think the protocol would make a sanity check on
incoming data so a sudden time (days/months/years) jump could not just
happen unless it was followed up with a few more in sequence or a special
code preceeding it.
I do understand that this protocol has some history behind it and that
incremental changes do happen from time to time (very bad joke - though I am
Again thank you for your help and your time.
Stephen A. Widmer
Widmer Time Recorder Co., Inc.
"David L. Mills" <mills at udel.edu> wrote in message
news:3F6730A9.C23812A8 at udel.edu...
> As it says in rfc-1305, a NTP timestamp of all zeros simply means the
> time has not yet been set or is unavailable. The fact this particular
> value is interpreted as the epoch of the next NTP era instead of the
> current one is an artifact of implementation and should be ignored.
> swidmer wrote:
> > Ihave seen in some case that NTP can and will reset a computers time to
> > year 2036. This seems to be the case when a machne senses a NTP time
> > that contain the time 00000000.00000000. This has seems to happen more
> > often on machines listening for NTP time broadcasts, but it also happens
> > machines using SNTP TCP requests.
> > Has anyone else seen this happen before? What can I do to avoid this
> > situation while still using NTP?
> > Oh one other thing to note, this problem generally happens when a
> > segement can no longer talk or listen to signals from other NTP Servers.
> > Thanks,
> > Steve
More information about the questions