4 ms·

I have no clue how widely implemented it is, but as far as NTP is concerned we're currently in era 0 which spans from 1900 to 2036. When we reach 2036, we just

by onei 5y ago

I have no clue how widely implemented it is, but as far as NTP is concerned we're currently in era 0 which spans from 1900 to 2036. When we reach 2036, we just move to era 1 and have another 136 years until we reach era 2. NTP itself should be resilient to this kind of issue by design.

floatingatoll 5y ago
Chances are, based on how poorly leap seconds and TLS 1.3 (and, I predict, http3/udp) are handled in actual reality by deployed systems, that a variety of software and hardware will fail inside infrastructure worldwide when ntp ticks over to era 2. https://news.ycombinator.com/item?id=28046997 https://news.ycombinator.com/item?id=28046997 https://news.ycombinator.com/item?id=13750379 https://news.ycombinator.com/item?id=13750379 https://news.ycombinator.com/item?id=27402222 https://news.ycombinator.com/item?id=27402222
xattt 5y ago
How many eras are possible in NTP?
- grogers 5y ago
  Infinitely many IIRC. Era isn't sent in the protocol, it's determined implicitly - if you know the time correctly to within a few dozen years you know the right era
  - foxfluff 5y ago
    So a device made in 2021 whose (1970 based?) RTC battery drained has no idea which era it is in 2036. Perfect.
    - Someone 5y ago
      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.
      - foxfluff 5y ago
        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.
        ectopod 5y ago
        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.
        tgsovlerkhgsel 5y ago
        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".
        Someone 5y ago
        That version has been in development for some time (https://www.rfc-editor.org/info/rfc5905 https://www.rfc-editor.org/info/rfc5905 is a proposed standard since June 2010) https://en.wikipedia.org/wiki/Network_Time_Protocol#Timestamps 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."
      - pdonis 5y ago
        > 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?
    - dathinab 5y ago
      Probably a bunch of devices will just jump to 1970 tbh. 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.
- tyingq 5y ago
  RFC5905 uses 32 bits for era number and 32 bits for era offset in the 128 bit timestamp type. Though I don't think the 128 bit timestamp is used much...I can't find support for it in either ntpd or chrony.
dtech 5y ago
We've seen time and time again that it doesn't matter what the spec says, if it works now, noncompliance will be there. Heck we're stuck with TCP & UDP because routers and firewalls will break anything else. If it works long enough, ossification makes it the new reality. How many NTP implementations don't consider era or contain bugs if era != 0?
- fanf2 5y ago
  There will almost certainly be failures in devices without battery-backed clocks (eg, Raspberry Pi) that boot in 1970 and rely on NTP to get the correct time, because NTP can’t tell them they are in Era 1 not 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.
  - asgeirn 5y ago
    From https://docs.ntpsec.org/latest/warp.html https://docs.ntpsec.org/latest/warp.html: > 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 Which means 2036 will appear to work just fine, as 1970 is only 66 years away. Now jump forward to 2038, and this would not be the case..
  - Unklejoe 5y ago
    > To fix this you need a persistent low water mark on the time 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.
Unklejoe 5y ago
I've implemented the 1588 protocol a couple of times, and I have less optimism. 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.

by onei 5y ago

floatingatoll 5y ago

Chances are, based on how poorly leap seconds and TLS 1.3 (and, I predict, http3/udp) are handled in actual reality by deployed systems, that a variety of software and hardware will fail inside infrastructure worldwide when ntp ticks over to era 2. https://news.ycombinator.com/item?id=28046997 https://news.ycombinator.com/item?id=28046997 https://news.ycombinator.com/item?id=13750379 https://news.ycombinator.com/item?id=13750379 https://news.ycombinator.com/item?id=27402222 https://news.ycombinator.com/item?id=27402222

xattt 5y ago

How many eras are possible in NTP?

grogers 5y ago
Infinitely many IIRC. Era isn't sent in the protocol, it's determined implicitly - if you know the time correctly to within a few dozen years you know the right era
- foxfluff 5y ago
  So a device made in 2021 whose (1970 based?) RTC battery drained has no idea which era it is in 2036. Perfect.
  - Someone 5y ago
    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.
    - foxfluff 5y ago
      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.
      - ectopod 5y ago
        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.
        tgsovlerkhgsel 5y ago
        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".
        Someone 5y ago
        That version has been in development for some time (https://www.rfc-editor.org/info/rfc5905 https://www.rfc-editor.org/info/rfc5905 is a proposed standard since June 2010) https://en.wikipedia.org/wiki/Network_Time_Protocol#Timestamps 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."
    - pdonis 5y ago
      > 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?
  - dathinab 5y ago
    Probably a bunch of devices will just jump to 1970 tbh. 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.
tyingq 5y ago
RFC5905 uses 32 bits for era number and 32 bits for era offset in the 128 bit timestamp type. Though I don't think the 128 bit timestamp is used much...I can't find support for it in either ntpd or chrony.

dtech 5y ago

We've seen time and time again that it doesn't matter what the spec says, if it works now, noncompliance will be there. Heck we're stuck with TCP & UDP because routers and firewalls will break anything else. If it works long enough, ossification makes it the new reality. How many NTP implementations don't consider era or contain bugs if era != 0?

fanf2 5y ago
There will almost certainly be failures in devices without battery-backed clocks (eg, Raspberry Pi) that boot in 1970 and rely on NTP to get the correct time, because NTP can’t tell them they are in Era 1 not 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.
- asgeirn 5y ago
  From https://docs.ntpsec.org/latest/warp.html https://docs.ntpsec.org/latest/warp.html: > 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 Which means 2036 will appear to work just fine, as 1970 is only 66 years away. Now jump forward to 2038, and this would not be the case..
- Unklejoe 5y ago
  > To fix this you need a persistent low water mark on the time 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.

Unklejoe 5y ago

I've implemented the 1588 protocol a couple of times, and I have less optimism. 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.