5

Wikipedia claims that NTPv4 supports 128-bit timestamps and indeed RFC5905 defines a 128-bit format called "NTP Date Format" in Sect. 6. The RFC says

The 128-bit date format is used where sufficient storage and word size are available.

However, when I send 128-bit timestamps to public NTP servers, there is no response. Furthermore, Sect. 7.3 defines all four timestamp fields to be 64-bit. To avoid Y2k38 bugs, I want to implement NTP properly using 128-bit timestamps. How can I get a server to respond with full 128-bit timestamps?

  • ntpdate seems to do it: reference time: e1d49463.09878698 Thu, Jan 23 2020 22:53:39.037 originate timestamp: e1d49469.1247687f Thu, Jan 23 2020 22:53:45.071 transmit timestamp: e1d49469.0d789064 Thu, Jan 23 2020 22:53:45.052 – stoney Jan 23 '20 at 21:55
  • No, those are 64-bit timestamps (32 bit integer and 32 bit fractional, both 8 hex digits). The 128-bit format has 64-bit integer and 64-bit fractional. – Jonas Mechtheim Jan 24 '20 at 07:03

1 Answers1

0

Old question but I stumbled here looking for the same thing. Page 13 of RFC5905 details that the expanded v4 format still contains a 32-bit value for seconds, but a signed 32-bit value for the era number. The seconds field in 128-bit date format is the offset within the era, so can handle dates far beyond 136 years. Seconds from prime epoch (1970) = era*(2^32) + era_offset(32bit seconds).