2000年問題、2012マヤ暦終了はまだヌルい。今後課題となるカレンダー問題。

オカルトとしての2012年マヤ暦終了はただ楽しんでいればよかったのですが、今後、カレンダーの終了・破綻はいくつか予定されています。

まず、過去のものとして有名なのは2000年問題がありました。

2000年問題とは、主にメインフレームと呼ばれる大型コンピュータで2000年になると同時に発生した日付処理の桁不足です。

古くから金融機関、証券会社、大手メーカーなどで使われているこの種のコンピュータでは、当時容量が少なく高価だった記憶媒体、記憶装置を少しでも効率的に使用するため、日付の年を下2桁だけで管理しているプログラムが多くありました。00(1900年)~99(1999年)と言った感じです。

そうなると当然99、つまり1999年の次の年を処理しようとすると2000年ではなく00、1900年に戻ってしまい、上手く日付を処理できません。

その為、当時は2000年になった瞬間にコンピュータシステムが大混乱を起こす！飛行機が落ちるぞ！などと言われたのです。

ただ、実際は小さい問題は発生しましたがあまり大きな問題は日本では起こりませんでした。

何故か、それは事前にこのような問題が発生することが明らかだったので対応するのに余裕があったこともありますし、2000年と言う切りの良い数字だったため認知度が高かったと言う事もありますが、何よりコンピュータシステムそのものではなくアプリケーション側でほぼ対応できる問題だったからです。プログラマを総動員してアプリケーションプログラムを直しさえすればいいのです。そして、コンピュータ自体には元々問題が無いため、事前にテストを行う事も可能であり、対応は粛々と行われ、そして概ね問題なく完了したのでした。

次に、昨年の2012年マヤ暦終了がありました。

ただ、今時マヤ暦を使用している人というのは極めて限られているので、部外者が騒ぐだけ騒いでおしまいでした。今後も特に問題となることは無いでしょう。

 

そして次からが未来の問題です。直近ではありませんが、2030年代になると連発します。

 

まず、2033年から2034年にかけて、旧暦が破綻します。

旧暦と言うのはもちろん日本の旧暦（天保暦）のことです。ちょっと大きめのカレンダーを買うと、旧暦が書かれているものは現代においても多くありますね。

旧暦の月を決定する際には、

• 春分を含む月は2月、夏至を含む月は5月、秋分を含む月は8月、冬至を含む月は11月になる

と言うルールがあるそうです。

なので、通常は問題なくとも、万が一秋分と冬至の間が1ヶ月分しか無かった場合などは、このルールが守れなくなってしまい、旧暦の月を決定できない・・・と言う事態になってしまいます。

そのルールが守れなくなる初めてのケースが、2033年秋~2034年春にかけて起こります。

旧暦は国としては終わった暦制度でありながら、年中行事など古くから伝わる伝統行事などは旧暦を基準として行われるものも多いため、実際決められないとなるとなにかと困りそうですね。

 

次に、2036年問題と言うものがあります。

コンピュータの時刻をネットワークを通じて同期するためのNTPと言うプロトコルがあるのですが、このプロトコルでは1900年1月1日0時0分0秒からの積算の秒数で時間を管理しています。

そしてこの積算の秒数は2の32乗-1秒後である4,294,967,295秒を超えるとまた0に戻ってしまう、と言う特徴を持っています。そこまでしか記憶するエリアが与えられていないからです。

その4,294,967,295秒後を迎えてしまうのが、2036年2月6日です。

その日を迎えてどうなるか。ネットワークで同期しているコンピュータの時間が一斉に1900年1月1日に戻ってしまうため、2000年問題の時と同じ問題が発生する可能性があります。2000年問題より更に悪いのは、これはアプリケーションではなくプロトコルの問題なので、アプリケーションプログラムを直せば解決する、と言うものでは無い点です。

2036年まで同じプロトコルを使い続ける事も無いような気はしますが、もし使ってるシステムが残っていたら・・・混乱が起きそうですね。

 

更に2年後、2038年問題と言うものがあります。

プログラム言語の中でも最もメジャーなものとして、C言語と言う言語があります。

このC言語では時間を管理するのにUNIX Timeと言う、1970年1月1日0時0分0秒からの積算の秒数を使用しています。

先ほどのNTPの70年後が起点となっていますが、これはただ実装した際に切りの良い過去の時刻だったと言うだけで、あまり深い意味は無いそうです。

そして、こちらの積算の秒数は2の31乗-1秒後である2,147,483,647秒をを超えるといきなり-2,147,483,648と言うマイナスの数になってしまう、と言う特徴を持っています。今度は正の数だけじゃなくてマイナスも表現できるエリアが割り当てられているんですね。

そうすると、時刻としては不正な値になってしまい、時刻は常に正しいものだと言うことを前提にしていると、エラーになってしまいます。

こちらも、アプリケーションプログラムだけで何とかなる問題ならいいんですが、プログラム言語自体、またコンピュータのOSやファイルシステム内部まで根深く影響する問題であり、C言語、そしてUNIX、Linuxを使用しているシステムというのは膨大な数であるため、対策が遅れれば2000年問題よりも影響は大きくなると言われています。

あとは、どれだけ2038年にこの組み合わせのシステムが生き残っているか、でしょうね。

自分は相当数あるんじゃないかと思います。

 

ヒトラーの2039年予言はこの事を見越しているのか・・・とか、考えちゃいますね。