2036 rollover

[jt]

Hello everybody,

I would like to be sure that all the systems synchronised by the ntp
servers on the LAN won't encounter problem due to the NTP timestamp
rollover in 2036.

Has this issue already been resolved a long time ago, and should I
consider that all the ntp daemon available today are not concerned by
this possible problem ?? Should I specify a minimum version of ntp
daemon ??

Maybe the answer of my question is already contained in the web page
"The NTP Era and Era Numbering" dedicated to this subject, but my
english or maybe my technical knowledge don't enable me to be sure.

Thank you,

JT

[David Mills]

jt.

As stated in the online white papers, as reported in the new book
edition and confirmed by actual experiment, if the NTP clock is set
within 68 years of UTC time, it will synchronized correctly, even if the
correction spans a rolloever epoch. However, this requires means to
convert UTC time to NTP era and timestamp format, and those Unix systems
known to me will rollover themselves in 2038, unless something is done
about it.

Davejt wrote:

>_______________________________________________
>questions mailing list
>ques...@lists.ntp.org
>http://lists.ntp.org/listinfo/questions
>
>

[Richard B. Gilbert]

jt wrote:
> Hello everybody,
>
> I would like to be sure that all the systems synchronised by the ntp
> servers on the LAN won't encounter problem due to the NTP timestamp
> rollover in 2036.
>

AFAIK NTP has NO problem with the year 2036!

There is a problem with some elderly Unix or Unix-like systems that
store time as a thirty-two bit count of seconds since 00:00 January 1, 1970.

I believe that most have been fixed to use a 64 bit counter which will
last for a while longer.

If the software you are using has been "fixed" the fix should be
documented somewhere. Since you haven't mentioned any specific hardware
and/or software it's difficult to provide any more specific answers than
I have done above.

<snip>