[PATCH] ntpd: make NTP client Y2036-ready
The 32-bit integer part of the NTP timestamp overflows in year 2036, which starts the second NTP era. Modify the timestamp conversion to shift values between 1900-1970 (in the first era) to the second era to enable the client to synchronize correctly until year 2106 (assuming 64-bit time_t). Signed-off-by: Miroslav Lichvar --- networking/ntpd.c | 3 +++ 1 file changed, 3 insertions(+) diff --git a/networking/ntpd.c b/networking/ntpd.c index 204e1d7c2..d0c61b4bb 100644 --- a/networking/ntpd.c +++ b/networking/ntpd.c @@ -565,6 +565,9 @@ lfp_to_d(l_fixedpt_t lfp) lfp.int_partl = ntohl(lfp.int_partl); lfp.fractionl = ntohl(lfp.fractionl); ret = (double)lfp.int_partl + ((double)lfp.fractionl / UINT_MAX); + /* Shift timestamps before 1970 to the second NTP era (2036-2106) */ + if (lfp.int_partl < OFFSET_1900_1970) + ret += (double)UINT_MAX + 1.0; return ret; } static NOINLINE double -- 2.35.1 ___ busybox mailing list busybox@busybox.net http://lists.busybox.net/mailman/listinfo/busybox
Re: [PATCH] ntpd: make NTP client Y2036-ready
On Monday, May 9, 2022, Miroslav Lichvar wrote: > The 32-bit integer part of the NTP timestamp overflows in year 2036, > which starts the second NTP era. > > Modify the timestamp conversion to shift values between 1900-1970 (in > the first era) to the second era to enable the client to synchronize > correctly until year 2106 (assuming 64-bit time_t). > > Signed-off-by: Miroslav Lichvar Is this the right fix where there is no check on the era number? ___ busybox mailing list busybox@busybox.net http://lists.busybox.net/mailman/listinfo/busybox
Re: [PATCH] ntpd: make NTP client Y2036-ready
On Tue, May 10, 2022 at 12:50:11AM +0800, Kang-Che Sung wrote: > On Monday, May 9, 2022, Miroslav Lichvar wrote: > > The 32-bit integer part of the NTP timestamp overflows in year 2036, > > which starts the second NTP era. > > > > Modify the timestamp conversion to shift values between 1900-1970 (in > > the first era) to the second era to enable the client to synchronize > > correctly until year 2106 (assuming 64-bit time_t). > > > > Signed-off-by: Miroslav Lichvar > > Is this the right fix where there is no check on the era number? What exactly would you want to check? The era number is not needed in the conversion until it's exchanged in the protocol (as was proposed for NTPv5). For now, it can only cover an interval of 2**32 seconds convering some part of two adjacent eras. -- Miroslav Lichvar ___ busybox mailing list busybox@busybox.net http://lists.busybox.net/mailman/listinfo/busybox
