Hacker News Reader

Comment by Someone | Hacker News Reader

A device made in 2021 could assume that the current time is at least 2021. Barring the invention of time travel and (a lot more risky) bugs assuming that NTP time stamps can be ordered by comparing them as 64-bit unsigned integers, that would make it OK for up to 2157 or so.

Working with that, conceptually, isn’t difficult. You can use any dateline as the epoch by subtracting the chosen epoch’s NTP timestamp from the one you received with wraparound.

Making a dateline library use that epoch for formatting dates and times isn’t hard, either, but could be a lot of work.

View on HN

Of course there are ways to make it work. I'm just assuming the vast majority of devs are not aware of this issue and mostly everyone's just solving their time problems by throwing NTP at it. Lots of things will break.

Absolutely. The only way we can be sure that this will be fixed by 2036 is by introducing a new NTP version that doesn't have this problem. Anything running the current version (which could be seen on the wire) would be considered broken.

That version has been in development for some time (https://www.rfc-editor.org/info/rfc5905 is a proposed standard since June 2010)

https://en.wikipedia.org/wiki/Network_Time_Protocol#Timestam...:

NTPv4 introduces a 128-bit date format: 64 bits for the second and 64 bits for the fractional-second. The most-significant 32-bits of this format is the Era Number which resolves rollover ambiguity in most cases. According to Mills, "The 64-bit value for the fraction is enough to resolve the amount of time it takes a photon to pass an electron at the speed of light. The 64-bit second value is enough to provide unambiguous time representation until the universe goes dim."

Luckily remediating this is relatively easy: Use some indicator for "certified 2036 proof" NTP clients that's visible on the network (a different port, an extension, ...), then observe the network to find legacy traffic.

Won't catch absolutely everything (e.g. local containers), but will probably get pretty close. Especially if modern NTP client versions have some way to resolve the ambiguity, e.g. a hardcoded "it's after 2020".

> A device made in 2021 could assume that the current time is at least 2021.

As long as the device knows it was made in 2021. But the device can't know that by magic; the manufacturer has to store that information in it somehow. Do all device manufacturers do that?

The time library used could compiler in the time of compilation, in which case the library user doesn't have to do anything/get it for free.

Yes, that would work too.

Reply on news.ycombinator.com