2000年問題の次の次の次

2000年問題というのが話題になったことがありますね。

当時はコンピューターの記憶容量の消費を抑えるために
西暦の下2桁だけを使って年を計算するシステムが多かったので
99 (1999年) の次の年は 00 となり、
1900年なのか2000年なのかわからなくなってしまい
コンピューターシステムに異常が発生するんじゃないか、という話。
懐かしいですね。

見えないところでいろんな人が頑張ってくれたおかげか
結局 知っている範囲では大きな問題は起きなかったんだけど、
コンピューターで扱う数字の桁に関しては
想定されている問題が他にいくつもあるみたい。

見てたらいくらか出てきたので、
目についたものをまとめてみます。

2038年問題

コンピューターで時間を表現するのに
UNIX 時間がよく使われますね。
1970/01/01 00:00:00 からの経過時間を秒で表すやつ。

32ビットの整数データ型が使われている場合
正の値は2,147,483,647までしか数えられないから、
UNIX 時間で2,147,483,647にあたる
2038年1月19日3時14分7秒の次の瞬間に数値がオーバーフローして
どっかで何か誤作動が起きるんじゃなかろうか、というのが
いわゆる2038年問題。

これを2000年問題よりややこしくしているのは

• 2000年問題より意味がわかりにくいので、エラい人に説明しても伝わりにくい。
• UNIX 時間は時差を持たないから、全世界で一斉に発生する。

というあたりでしょうか。

まだ2038年にはなってないけど、
時間の計算をする過程で数値がオーバーフローしてしまい
トラブルが発生したという事例は既にあるようです。

10000年問題

2000年問題をクリアして以降
多くのシステムでは西暦を4桁の整数で表しているので
西暦9999年の次は桁が溢れてしまうという話。
これはわかりやすいですね。

2038年問題はもうすぐだけど、
まあ10000年問題のことは
あと7900年ぐらい経ってから考えますか。

292277026596年問題

2038年問題をクリアする方法として
時間を扱うのデータの型を
32ビットから64ビットに変更するというのがありますね。
そうすれば UNIX 時間で
9,223,372,036,854,775,807 までカウント可能。

ただ、桁を増やしても
いずれオーバーフローが発生するというのは同じこと。
次は西暦2922億7702万6596年12月4日に溢れます。

他にもいろいろありそう

2038年問題と似たような話だけど、
Windows や NTP では1900年からの秒数を符号なし32ビットで扱うから
4,294,967,295秒後の2036年2月6日に発生する「2036年問題」とか
いろいろ節目のタイミングはありそう。
他にもご存じだったら教えてください。

永遠とか完全とか絶対とかいうことはないので
常に「次の問題」は存在しますね。

まあ人間のやることは完璧にはならないし
いずれは地球がなくなったり太陽が消え去ったり宇宙が消滅したりするので
それまでは一生懸命に生きていきましょう。