I would like to check if the "ntpdate" utility from NTP handles the issue of 2036 roll-over. For this, I would like to implement an NTP server which generates a static timestamp after the roll-over time: 2036-02-07/06:28:15.
I am currently stuck at the point of understanding how NTP addresses this issue. I see NTPv3 protocol does use 64-bit timestamps (32-bit seconds, 32-bit usec(fraction)) and I also see that new NTPv4 standard defined in rfc5905 page12 addresses this issue by defining three different data types.
There are three NTP time formats, a 128-bit date format, a 64-bit timestamp format, and a 32-bit short format
But in the defined "packet header format" defined in page 18, timestamp used just holds 64-bit timestamp format. There is no other mention anywhere in the document as to how we can incorporate the "128-bit date format", which includes the "era" and "era offset" data defined to address the roll-over issue.
"ntpdate" utility claims it supports NTPv4 standard so I was guessing it should support the 128-bit timestamps as well. I have also went through the source code of ntpdate to see if there is any support for "era" or "128-bit timestamp" formats but I could not find any pointers to suggest that 'ntpdate' could handle 128-bit timestamps.
From my understanding, NTP introduced in NTPv4 protocol, a 128-bit date format which should be used to solve the roll-over issue. Is my understanding correct? and are there any other opensource servers available online to investigate the behaviour of 'ntpdate' or 'ntpd' utilities for 2036 roll-over issue?
Thanks in advance!
After a lot of research, I was able to come up with this link, where the issue is explained clearly.
It turns out we can always send only the time-stamp in 64-bit format as deined without bothering about era's. In Charpter 6 of rfc5905, the explanation is given as to how to determine the time-stamp from Prime-epoch time.
To convert system time in any format to NTP date and timestamp formats requires that the number of seconds s from the prime epoch to the system time be determined. To determine the integer era and timestamp given s,
era = s / 2^(32) and timestamp = s - era * 2^(32)
and same is explained with an example in the above link. I still wonder why NTPv4 bothered to define "128-bit date format" and where exactly it is used, but this is not the scope of this question.
Also the possible limitations to add here are: these calculations will only work for the adjecent eras and only if the client is set within 68 years of the server because of signed arthematic. Quoting from Section 6, Page 5
In point of fact, if the client is set within 68 years of the server before the protocol is started, correct values are obtained even if the client and server are in adjacent eras.
Thank you!