要約

  • RFC 868は1900年1月1日からの秒数を32ビットで表し、TCPまたはUDPの37番ポートで返す仕様だった。
  • 2036年という限界は後から見つかったものではない。標準自身が明記していたが、具体的な周回時刻は書いていない。
  • NTPは一つの時刻値を返すだけでなく、複数の時計を同期し、数値がどの時代に属するかを解釈する役割を担った。

返すのは時刻のサンプル

1983年にはカレンダー時計を持たないシステムもあり、機械や人の誤りで時刻がずれることもあった。RFC 868は、複数の独立したサイトへ短く問い合わせ、その応答を使って自分の時刻を確かめる方法を示した。共通の数値を決めた一方、完全な時計同期処理までは定義していない。

値は1900年1月1日00時00分GMTからの経過秒数である。サーバーは37番ポートで待ち受ける。TCPでは接続後に32ビット値を返して閉じる。UDPでは空のデータグラムを受け、時刻を含むデータグラムを返す。自分の時刻が分からないとき、サーバーは値を作ってはならない。TCP接続を拒否または値なしで閉じるか、UDPに返答しない。

複数のサイトを比べる提案はあるが、ネットワーク遅延の補正、信頼できる送信元の選択、認証、ローカル時計の調整は書かれていない。機械で読めることと、正確さが保証されることは別である。

ASCIIのDaytimeとの役割分担

同じ月に出たRFC 867 Daytimeは、13番ポートからASCIIの日時を送る。デバッグや測定には便利で、印字可能文字を勧めるが、日付の書式を一つに決めない。機械向けにはRFC 868を使うよう注記している。これは表示方法と用途の違いであり、両サービスの時計の正確さを比べる根拠ではない。

1900年という起点は、Unix時刻で一般的な1970年より前だ。RFC 868は換算例を示す。1970年1月1日00時00分GMTは2,208,988,800となる。共通の原点があれば機械同士で数値を比べられるが、両方が同じ単位を使わなければならない。

仕様はこの表現の期限も明示した。「この基準は2036年まで」とある。1900年からの符号なし32ビット秒数が2³²に達するのは2036年2月7日06時28分16秒GMTだ。これは起点と幅から求めた計算で、RFCが示すのは年までである。次の秒は格納できず、値はゼロへ戻る。時代を示す別の情報がなければ、周回後の値を最初の周回の値と見分けられない。

NTPが引き受けた追加課題

1985年のRFC 958は、Network Time Protocol（NTP）をRFC 868とICMP Timestampから発展し、双方を置き換え得る仕組みと説明する。NTPの目的は、分散したクライアントとサーバーで複数の時計を同期することだった。単一の時刻サンプルを返すだけではない。

NTPも1900年の起点を保ったが、時代の扱いを追加した。後のRFC 5905は32ビット秒フィールドと、2036年に時代0から時代1へ移ることを記述する。送信時刻には秒と小数部があるものの、より大きな時代は文脈から読み取る必要がある。現在時刻のおおよその範囲があれば、周回付近の値を解釈できる。

つまり一つの形式が無期限になったわけではない。RFC 868は小さな固定値で問い合わせを簡単にし、その有効な期間も示した。NTPは同期と時代解釈を別の課題として加えた。1900年をネットワークに載せた時点で、2036年の境界も標準に書かれていた。数値一つでは、その先の時間を永遠に説明できない。

出典と限界

主な一次資料は1983年5月のRFC 868, Time Protocol。RFC 867は同時期のASCIIサービス、RFC 958はNTPが述べる系譜、RFC 5905は後の時代処理を示す。これらはRFC 868サーバーの実数や精度、全体的な移行、2036年の障害を証明しない。

RFC 2626も2036年の周回を指摘するが、そこに記された具体的な分は上記の計算と一致しない。ここでは年の境界を認識していた記録としてのみ用い、その時刻は採用しない（RFC 2626）。Heng LuのNote 65は、実装が書かれた規則をどう受け継ぐかという編集上の問いに使ったもので、歴史的証拠ではない（Note 65）。