2001年9月9日問題（2001年9月9日）

　西暦2000年問題。西暦2000年を迎えるに当たりコンピュータの日付の処理に大きな問題が生じる可能性が指摘された問題です。昔のコンピューターは日付を文字列として扱っていましたがメモリの節約のために西暦の上位2桁を省略し、下位2桁のみを記録していました。従って2000年を迎えると、コンピュータの日付の西暦の部分が00になってしまい、1900年と処理されてしまう可能性がありました。しかし、当時、多くの技術者たちは西暦の処理については将来新しい技術が出てくるだろうと考えて、プログラムを開発するにあたり特段の対策は考えていませんでした。また、これはとは別に2000年を閏年の処理をしないように作られているプログラムもありました（2000年2月29日問題）。そして何らの対策もないまま1990年代後半を迎えたのです。

　多くの技術者は既存のプログラムの内容を確認し必要に応じて修正を行いました。開発に関わった技術者がすでに退職していることなどもあり作業には手間がかかりました。また2000年問題によって物流や金融などで深刻な問題が起こる可能性があると大きく取り沙汰されたこともあり必要以上に慎重な対応をせざるを得なかった面もありました。大きな社会問題となりましたが、技術者の尽力によって2000年を迎えても大きな問題は起こらず収束しました。

　コンピュータの日付の処理には2001年9月9日問題もありました。これはプログラムで時間を管理するデータ型が1970年1月1日午前0時を起点とした経過秒数となっており、2001年9月9日に十進法で10桁（1,000,000,000秒）を超えることでコンピューターの処理に問題が発生する可能性が指摘されたものです。しかしながら、このデータ型は符号付きの32ビットで最大値が2,147,483,647となるため、時間の扱いに本質的な問題が生じるのは2038年1月19日未明で、2001年9月9日問題が起こるとは考えにくいという指摘もありました。

　ところが現実には2001年9月9日問題が発生したシステムも出ました。ほとんどの原因は経過秒数を文字列として扱っていたためです。文字列で数字の大小比較をすると999999999の方が1000000000より大きいと判断されてしまうため、正しく日付順に並べることができなかったり、新しいデータと判断されずに処理が行わなかったり、古いデータと判断されてデータが削除されたりする問題が発生したのです。

　このデータ型の問題は桁数の繰り上がりで生じるため2001年9月9日以前も発生していたはずです。しかし、1970年1月1日午前0時を起点とした秒数が9桁になったのは1973年であり、当時稼働していたプログラムはそれ以降に開発されたものがほとんどだったため長きに渡りこの問題が生じることがなかったのです。

　なお2038年問題はデータ型を符号付き64ビットにすることで西暦3000年まで、64ビット化ができない旧システムの場合は符号なし32ビットとすることで2106年まで回避できる見通しです。

【関連記事】

・自動販売機のチェックサムエラー

・世界初の電子掲示板（BBS）が登場（1978年2月16日）

・NCSA Mosaic がリリース（1993年4月22日）

・Twitter記念日（2009年11月16日）

・テレワーク・出張・お出かけに便利なグッズ　電源アダプタや充電器など

人気ブログランキングへ