かるた無病息災

こんばんは、仕事場で「あれっ？この缶は一体何だ？」と思って開けてみたら、中身は10年前のクッキーで、中の空気を吸った瞬間に咳が止まらなくなってしまったHaRDです。

そんなものを置きっぱなしにしてるんじゃねー！！まぁ、開けてみた僕も悪いんですけどね。賞味期限は2000年……ついこの前のように感じるけど、もう10年も経ったんですね。

咳き込みながら僕は、「2000年と言えば『2000年問題』があったなぁ……って、『2038年問題』も段々と近づいてきてるじゃん！」と思った。せっかくなので、これらの問題について知らない人のために簡単に説明します。プログラム等に強い人には常識的な話なので読み飛ばしてください(笑)

2000年問題

プログラムで、西暦の「1998年」の表記を「98」のように下2桁で扱っている場合、「2000年」が「00」となってしまい、「1900年」と間違ってしまい誤作動を起こしてしまう問題が懸念された。

また、閏年は一般的に「西暦が4で割り切れる年」や「オリンピックが行われる年」などと覚えられているが、「西暦が100で割り切れる年」は例外的に閏年ではありません。しかし、さらに例外があり、「西暦が400で割り切れる年」は閏年になります。

つまり、閏年の判断プログラムで「100で割り切れる場合」だけに対応して、「400で割り切れる場合」に対応していないと、バグが発生してしまうのではないかと懸念された。

僕の記憶だと、結局は大きな問題にならなかったと思います。ただ、この時期のプログラマやSE、そして修復のために費用を払うことになった企業は大変だったでしょうね……

2038年問題

パソコン等で時間を扱う場合、多くはUNIX時間を使って表されます。これは、1970年1月1日から何秒経過したかを数値化したもので、例えば「2010年02月17日1時2分3秒」は、UNIX時間で「1266336123」として扱われます。

UNIX時間を使うと、時差などの問題も比較的楽に解決できるのですが、2038年1月19日になると「2147483647」を超えてしまうんですよね。

中途半端な数字に見えるかもしれませんが、「2147483647」は「2³¹ - 1」の値であり、プログラムの数値データの型によってはこの値が最大値なのです。許容量を超えたデータを受け取ったプログラムは、誤作動を起こしてしまう可能性が高いでしょう。

つまり、2038年1月19日になったときに、今のままでは様々な機器で誤作動が発生してしまうのです。

ちなみに、僕のケータイを調べたところ、カレンダーは「2037年」までしか見ることが出来ませんでした。いつ頃から対応し始めるんでしょうかね。