The client and server's times differ by 136 years.

[sweetbreeze-wang]

When I set the time on the NTP server to the year 2000 and the client's time to the correct year 2023, and then use NTPD as the client to synchronize with the server, the client's time is changed to the year 2136

If the NTP server's time is set to the year 2004, the NTP client's time changes to the year 2140, with a difference of 136 years. This issue persists even with the latest version of NTP, version 4.2.8, but is not present when using version 4.2.6p5.

[hart-NTP]

This behavior is intentional. ntpd now builds in a "base date" at compile time. At least with "logconfig allall" in ntp.conf, this is logged at startup:

10 Oct 20:35:28 ntpd[5028]: proto: precision = 0.200 usec (-22) 10 Oct 20:35:28 ntpd[5028]: basedate set to 2023-07-26 10 Oct 20:35:28 ntpd[5028]: gps base set to 2023-07-30 (week 2273) 10 Oct 20:35:29 ntpd[5028]: initial drift restored to 12.392000 10 Oct 20:35:29 ntpd[5028]: Listen and drop on 0 v6wildcard [::]:123

The basedate logged is used to interpret NTP 64-bit fixed-point timestamps as received over the network, which have a 32-bit seconds count that spans 136 years. Your client ntpd is reasoning that the received NTP timestamp which the server provided cannot be earlier than the basedate set at the time ntpd was compiled, so it is interpreted as being in 2136, not 2000. This behavior is to provide the best future-proofing for ntpd binaries used long after they were compiled. If you really require setting your client clocks to 2000, you'll either have to use an earlier version of ntpd (not recommended) or build the latest ntpd on a system with the clock set before 2000.

Incidentally the GPS base date is used similarly for GPS-provided timestamps in reference clock drivers. GPS timestamps use a 10-bit week counter spanning 1024 weeks, or just under 20 years. When a stratum 1 ntpd processes a timestamp from a GPS receiver, if the GPS receiver firmware is buggy or out of date the reported date & time may be ~20 or ~40 years earlier than the correct time, and again the timestamp is interpreted must be after the date and time ntpd was built. Notice the gps base logged above is week 2273, so there have already been two GPS 1024-week rollovers which a recent ntpd will handle correctly even with a buggy/old GPS receiver reporting a date/time 1024 or 2048 weeks less than the correct time.

[hart-NTP]

Harlan Stenn asked if we should have a "basedate" option in ntp.conf and it turns out we already do, though it's missing from the documentation and will probably change before it's documented. If your 4.2.8 client is recent enough (you don't mention the full version number) you may be able to avoid rebuilding it on a system with the clock set before the year 2000 by adding a basedate giving the number of days since Dec 31 of the year 0. 1998 should be 365.25 * 1998 or 729769, so add to the client ntp.conf:

basedate 729769

and you should see the basedate logged at startup be near Jan 1 1998 and be able to sync to your server's year 2000 time.

[sweetbreeze-wang]

The mechanism for confirming basetime based on compilation time was introduced from which version,  and what is the basis for basetime in older versions ？

------------------ 原始邮件 ------------------ 发件人: "ntp-project/ntp" @.>; 发送时间: 2023年10月19日(星期四) 下午2:13 @.>; 抄送: "sweet @.**@.>; 主题: Re: [ntp-project/ntp] The client and server's times differ by 136 years. (Issue #15)

Harlan Stenn asked if we should have a "basedate" option in ntp.conf and it turns out we already do, though it's missing from the documentation and will probably change before it's documented. If your 4.2.8 client is recent enough (you don't mention the full version number) you may be able to avoid rebuilding it on a system with the clock set before the year 2000 by adding a basedate giving the number of days since Dec 31 of the year 0. 1998 should be 365.25 * 1998 or 729769, so add to the client ntp.conf:

basedate 729769

and you should see the basedate logged at startup be near Jan 1 1998 and be able to sync to your server's year 2000 time.

— Reply to this email directly, view it on GitHub, or unsubscribe. You are receiving this because you authored the thread.Message ID: @.***>

[sweetbreeze-wang]

Why is the mechanism of introducing compile time as a basedate  introduced to solve what problem?

------------------ 原始邮件 ------------------ 发件人: "ntp-project/ntp" @.>; 发送时间: 2023年10月19日(星期四) 下午2:13 @.>; 抄送: "sweet @.**@.>; 主题: Re: [ntp-project/ntp] The client and server's times differ by 136 years. (Issue #15)

Harlan Stenn asked if we should have a "basedate" option in ntp.conf and it turns out we already do, though it's missing from the documentation and will probably change before it's documented. If your 4.2.8 client is recent enough (you don't mention the full version number) you may be able to avoid rebuilding it on a system with the clock set before the year 2000 by adding a basedate giving the number of days since Dec 31 of the year 0. 1998 should be 365.25 * 1998 or 729769, so add to the client ntp.conf:

basedate 729769

and you should see the basedate logged at startup be near Jan 1 1998 and be able to sync to your server's year 2000 time.

— Reply to this email directly, view it on GitHub, or unsubscribe. You are receiving this because you authored the thread.Message ID: @.***>

[hart-NTP]

Please see https://bugs.ntp.org/3882, sweet.

[hart-NTP]

I was mistaken about basedate. It is documented and it takes days since 1900 or a YYYY-MM-DD format date. See https://www.ntp.org/documentation/4.2.8-series/miscopt/ under "tos basedate" (note it's not simply "basedate", the "tos" prefix is needed).