如果廣播日期太高，NTP 客戶端忽略伺服器
我讀到了 NTP 的 2036 問題，我決定對其進行一些測試。我的伺服器從他的本地時鐘獲取時間，而我的客戶端僅從該伺服器獲取時間（甚至不是他的本地時鐘）。
我將伺服器日期更改為
01 JAN 2040 12:00:00，客戶端正在輪詢伺服器並將其日期更改為 2040。我在客戶端上執行 NTP 版本 4，此問題是否已修復？如果是，是版本 4 還是更早版本？之後，我決定將伺服器日期更改為 2070 年。現在客戶端忽略伺服器，它可以看到它，輪詢達到 377，已經過去了 5 多分鐘，但它從未同步到它。他似乎因為約會錯誤而忽略了它。
您知道在客戶端忽略它之前伺服器可以廣播的最長時間嗎？
我進行了相當多的簡化，因此那些有興趣深入研究的人應該閱讀相關的 RFC、其他文件和有關該主題的網頁。
NTP 不會正確同步到超過大約 68 年不同步的源。NTP 使用 64 位時間戳，其零值是 1900 年 1 月 1 日，但在有線協議上，它被截斷為 32 位。不通過網路發送的高 32 位是NTP 時代，大約 136 年的時間。NTP 時代 0 從 1900 年 1 月 1 日執行到 2036 年 2 月 7 日，當 32 位值從 4294967295 翻轉到 0 時，NTP 時代 1 開始。因為 NTP 時代不是通過網路發送的，所以 NTP 客戶端會假設源應該在其自身時鐘的 2147483648 秒（大約 68 年）內。如果相差超過68 年，客戶端要麼設置錯誤的時間，要麼拒絕同步。
這在 2036 年 NTP 時代結束時不太可能成為實際問題，因為大多數係統已經將時鐘設置為 68 年內的值，但在 2038 年基於 32 位 UNIX 的操作時，這可能是一個更大的問題系統的時鐘從 2038 年翻轉到 1901 年。它們不僅不再與 NTP 同步，而且當它們執行的任何應用程序由於無效日期而出現異常時，它們將引發 Y2K 式的混亂。
最終，您的客戶端錯誤日期為 49 年應該同步，但如果 NTP 客戶端只是旋轉，您和您認識的每個人都會在它發生之前很久就死了。沒有人願意等待 98,000 年才能同步他們的時鐘，這就是為什麼會出現巨大差異的原因。請注意，如果時鐘遠不同步，ntpd 可能會等待多達 15 分鐘，然後再步進。你說你只等了五分鐘。NTP 客戶端或作業系統中可能還會發生其他不太有趣的事情，因為實際上我們將手動設置時鐘並繼續我們的一天。