News for hackers. Stuff that matters.

A comment on Glibc is still not Y2038 compliant by default. Parent comment

Re:Glibc is still not Y2038 compliant by default by dtech on Wednesday December 29, 2021 @06:13AM (#29723834)
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?

[ Parent | on HN ]
Re:Glibc is still not Y2038 compliant by default by fanf2 on Wednesday December 29, 2021 @07:11AM (#29724100)
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.

[ Parent | on HN ]
Re:Glibc is still not Y2038 compliant by default by Unklejoe on Wednesday December 29, 2021 @09:07AM (#29724894)
> 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.

[ Parent | on HN ]
Re:Glibc is still not Y2038 compliant by default by asgeirn on Monday January 03, 2022 @05:09AM (#29779138)
From 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..
[ Parent | on HN ]