扇動的なタイトルにしたけれど、若干釣りがはいっている。

13年前に騒いだ2000年問題の再来のようなものが2038年にも発生するという話。

あの時は西暦が下二桁でしか内部で表記していなかったため、99年から00年になるという問題だった。
ミサイルが誤射されるとか言われたり、ノストラダムスの予言と相まって
終末論的な騒がれ方をした。

あの問題は大したことはなかったけれど、何年も前から修正を行なっていたため無事になった。
今回の話も何年も前から対処をしていればきっと大丈夫。

2038年問題

コンピュータ内部での時間はUNIX時間という考え方で計算されている。
これは1970年の1月1日から数えて何秒目なのかという数え方をしている。

コンピュータ内部で数値を扱うときには、メモリで使う範囲を確保して数値を計算する。
その確保されたメモリ範囲以上の数値は使えない。
多く確保したらその分だけ大きい計算もできるけれど、大量にメモリを確保すると使える分が減ってしまう。

昔ながらの実装だとその時間を計算している数値の範囲は-21億~21億の間の数値しか使えない。
マイナスってのはありえないから、実質0~21億

1970年1月1日から2,147,483,647秒後というのは2038年1月19日3時14分7秒だそうだ。
つまり、その時間を超えたらその昔ながらの実装である古いコンピュータは何か不具合が起きる。

オーバーフロー

使える数値を超えて計算をするとオーバーフローしてしまう。
アプリによっては予期せぬエラーが起こったという事で強制終了をしたり、
エラーをキャッチして安全に停止したり、無視したりするかもしれないけれど、
そういう考慮をしていない場合もある。

2の補数

コンピュータ内部では負の数を計算するときには負の数として扱っていない。
補数という考えを使っていて、
詳しい説明を省くが、
数値のデータ型に1加算するとメモリ内の2進数の数値も1加算されるが、正の数上限値に1加算すると負の数の下限値になる。
これは加算機能だけで減算も簡単にできるという仕組みなのだが、
つまり、UNIX時間の上限値を超えたら数値はマイナスになってしまうということだ。

予期せぬ数値が発生したらそのプログラムは止まるか、何か深刻な誤作動を起すかもしれない。

対応

上限を増やしておけば問題は無いわけで64bitにすると上限はずっとずっと先になる。
3000億年後になる。
そして今のOSなどは64bitで計算されているから問題はない。

だが、この計算はOSなどコンピュータの最も基礎的な部分で動いている。
家で例えると土台だ。
2000年問題は、家で例えると窓とか屋根とか建ってからでも用意に変更できる部分だったけれど、
この場合は容易に変更ができない土台だ。

そして何十年も安定稼働し続けているシステムというのは存在するし、
そのシステムにつながるAPIなどにも影響がでるかもしれないので、つながっている先のアプリなども変更が必要かもしれない。
修正する範囲はとても広くなる。
古い設計をそのまま秘伝のタレのように継ぎ足し修正していったものだったら、そういう実装が残る可能性だってある。
遠い未来だからといっても安心できる問題ではない。
人類滅亡レベルに心配することはないと思うけれど、新しい終末論に飢えているならば
2038年に来たる死を夢見て生きてほしい。