2000年を迎えるとき、世界は「Y2K」というコンピューターのバグを話題にしました。そして次に控えているのが別の日付、2038年1月19日です。その日、時刻が03:14:07(UTC)を1秒過ぎた瞬間に、一部の古いコンピューターはカレンダーを一気に1901年に戻してしまうかもしれません。これはSFのシナリオではなく、単純な算数の問題です。
コンピューターはどう時間を数える?
Unixと、そこから派生した多くのシステムは、時間を時計やカレンダーとしてではなく、1つの数として保持します。その数は、1970年1月1日の真夜中(UTC)から経過した秒数です。これを「Unix時間」と呼びます。
問題は、この数が多くの古いシステムで、符号付き32ビット整数として保存されていることです。符号付き32ビット整数が取れる最大値は2,147,483,647、つまり2の31乗マイナス1です。この秒数は約68年に相当します。「符号付き」とは、1ビットを数がプラスかマイナスかを示すために使うという意味です。そのため、32ビットのすべてではなく、31ビットだけが大きさに使われます。
1970年に68年を足すと、2038年に届きます。計算すると、ちょうど2038年1月19日03:14:07 UTCになります。
1秒後に何が起きる?
カウンターが最大値に達した1秒後、桁あふれが起こります。昔の車の機械式走行距離計を思い浮かべてください。999,999の次は000,000に戻ります。ここでも似たことが起こりますが、符号付きの数なので、値は非常に大きなマイナスの数に変わります。
影響を受けるシステムは、このマイナスの数を、1970年から遡って数えた秒数と解釈します。その結果、日付は1901年12月13日20:45:52(UTC)と表示されます。一瞬で136年も過去に戻ったコンピューターでは、証明書、タイマー、ログ、日付の比較が誤作動を始めるかもしれません。
誰がリスクにさらされている?
日常で使っている最近のスマートフォンやパソコンの大部分は、すでに64ビットの時間値を使っています。本当のリスクは、長年更新されないまま動き続けているシステムにあります。Wikipediaは特に、レガシーシステムと組み込みシステムを挙げています。産業用制御機器、一部のネットワーク機器、車載システムのように、一度設置したら忘れられる機械です。
こうした機器はあまり更新されないため、2038年になっても、内部に32ビットで時間を数える部品が残っているかもしれません。
| 符号付き32ビットの時間 | 符号付き64ビットの時間 |
|---|---|
| 最大値は2,147,483,647 | はるかに広い範囲 |
| 限界: 2038年1月19日 | 限界: 約2920億年後 |
| 古いシステムと組み込みシステム | 現代のOS |
解決策: もっと大きなカウンター
ここでの難しさは、技術的というより現実的なものです。時間を保持する数のサイズを変えると、その数を使うすべてのプログラム、すべてのファイル形式、データベースのすべての項目に影響しかねません。1行を直すのは簡単ですが、機器の中のソフトウェアをすべて見つけて更新するには、何年もかかることがあります。
解決策は、考え方としては単純です。時間を64ビットの符号付きの数で保持すること。Wikipediaによれば、これで桁あふれの瞬間は約2920億年後まで遠のきます。つまり、現在の宇宙の年齢をはるかに超えています。
この移行は何年も前から進んでいます。Phoronixの2020年1月の記事によると、Linux 5.6は、32ビットシステムが2038年以降も動けるようにする土台となりうる、最初のメインカーネルリリースとして準備されていました。Wikipediaは、2020年にリリースされたLinux 5.6が、32ビットアーキテクチャに64ビットの時間のサポートを加えたと述べています。これが機能するには、アプリケーションも64ビットの時間で再コンパイルされる必要があります。
別の解決案は、数を符号なし(unsigned)にすることです。しかしこれだと限界が2106年に移るだけで、1970年より前の日付が使えなくなります。そのため、本筋は64ビットへの移行だと考えられています。
Y2Kは大惨事にならずに済みました。人々が前もって取り組んだからです。2038年までの残りの年月でも、同じ静かな奮闘は繰り返されるでしょうか?