How many NTP implementations don't consider era or contain bugs if era != 0?
To fix this you need a persistent low water mark on the time, compiled into the NTP program and/or stored in the filesystem (eg the timestamp on the NTP drift file). Then NTP timestamps can be interpreted as spanning the 136 years after the low water mark, using modular arithmetic.
Yep, this is what many GPS receivers do to deal with the 20 year issue. They burn their manufacturing date, so they know which "cycle" they're in.
> The NTP protocol will synchronize correctly, regardless of era, as long as the system clock is set initially within 68 years (a half-era) of the correct time
https://news.ycombinator.com/item?id=28046997
This "era" thing seems like the exact type of thing that someone would ignore when implementing the protocol, or if it is supported, probably doesn't get tested much. It's like leap seconds. Yeah, the leap second info is conveyed in PTP, but most of the implementations I've seen simply ignore it and just jam the clock when the time jumps.
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.
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."
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".
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?
Through if you do it properly you add some fixed known min . time (like manufacturing time, or time of the last system software/is update) and if the NTP time is noticable below the min time you increase the epoch by 1.
E.g. in you case the device could know it's revision had a min. time of idk. 2015. Then if it receives 1973 it knows it's 3 years in the next epoch.
But as anyone can guess there will be devices which didn't implement that at all and will end up in 1970. Or which require setting time by hand and will end up in 1970 because it truncates to 32bits at some point or similar.
Through some embedded devices might happen to avoid it. Like due to special reasons they might use a non-unix epoch.