私は現在、特定のプロジェクトに対する 2036 年と 2038 年のロールオーバー バグの影響を調査しています。このプロジェクトによって実装されるソフトウェアは、これら 2 つの日付を超えて実行できる必要があります。
私の最初の調査では、2036 年の NTP タイムスタンプのロールオーバーは、プロトコルが維持されているため、実際には問題ではないことが示されています。
現在の問題は、64 ビット OS で実行されている NTP クライアントが 32 ビット OS で実行されている NTP サーバーに同期されている場合の 2038 ロールオーバー状態に関連しています。この状況下で 64 ビット システムが正しく同期されないかどうかは誰にもわかりませんか? NTP プロトコルはモジュロ演算と相対 NTP タイムスタンプを使用して同期オフセットを計算することに注意してください。
まず、32 ビット マシンが組み込み分野以外で販売される可能性は、来年の時点でもありそうにありません。
第 2 に、より優れた 32 ビット OSは、部分的または完全に時間的な目的で 64 ビットに既に切り替えられており、エポックを処理するためのフラグ フィールドが追加されているだけでもあります。したがって、実行中の OS も同様に古いものになりますが、これはありそうもありません。
第三に、そのような壊れたマシンの NTP サーバー (NTP タイムスタンプは単なる OS タイムスタンプではないことに注意してください) がこれを処理する可能性があります。
第 4 に、そうでない場合は、おそらく同期できません。
私の知る限り、いいえ--NTPはこれらの2036/2038日付と32対64ビットマシンを処理できます。
ただし、余談ですが、監視時間は 2004 年 1 月 10 日土曜日 13:37:04 GMT+0000 (1970 年 1 月 1 日 00:00:00 + 0x3ffffffff 秒) でした。クライアントからサーバーへの時間差が > 0x3ffffffff 秒 (~34 年) で、「バディ エポック」がない場合、NTP は同期しない可能性があります。Dr. Mills の「Computer Network Time Synchronization: The Network Time Protocol」の 9 ページと 216 ページを参照してください。正確性の原則に準拠するには、プロトコルが開始される前に、システム クロックを現在の UTC 時間から 34 年以内に設定する必要があります。」RTC バッテリが切れたときに再起動した後、本番環境でこれにヒットするシステムに遭遇しました (1970 年 1 月 1 日木曜日 00:00:00 GMT に発生しました)。