2000年問題
2000年問題
ところが、西暦2000年が近づくにつれて、この表記が問題視されるようになってきた。なぜなら、1999年12月31日 "99-12-31" の翌日は "00-01-01" となり、日付の前後を文字列の大小比較で行っているような処理では \( \text{"99-12-31"} \gt \text{"00-01-01"} \) となってしまうからだ。
つまり、2000年1月1日として扱わなくてはいけないのに、1900年1月1日と誤認識してしまい、プログラムが不具合を起こす可能性が出てきたのだ。これを「2000年問題（y2k問題）」と呼ぶ。
未来日で予約する航空券などの交通系システム、月締めする金融系システムなどで不具合が発生することが予想された。これらのシステムでは、後述する対策を計画的に進めていたのだが、マスコミが大げさに報じたものだから、日常生活が混乱し世界の破滅につながるといった、いまでいうフェイク情報が拡散した。『ノストラダムスの大予言』（五島勉＝著、1973年、祥伝社）を引用するフェイクニュースもあった。
つまり、2000年1月1日として扱わなくてはいけないのに、1900年1月1日と誤認識してしまい、プログラムが不具合を起こす可能性が出てきたのだ。これを「2000年問題（y2k問題）」と呼ぶ。
未来日で予約する航空券などの交通系システム、月締めする金融系システムなどで不具合が発生することが予想された。これらのシステムでは、後述する対策を計画的に進めていたのだが、マスコミが大げさに報じたものだから、日常生活が混乱し世界の破滅につながるといった、いまでいうフェイク情報が拡散した。『ノストラダムスの大予言』（五島勉＝著、1973年、祥伝社）を引用するフェイクニュースもあった。
対策方法
実際には、停止や不具合を起こすシステムはほとんどなかった。それは次のような対策を施したからだ。
根本的な是正策は、yy-mm-dd で記録していたのを yyyy-mm-dd 記録に改めることだ。
だが、これを実行するには
根本的な是正策は、yy-mm-dd で記録していたのを yyyy-mm-dd 記録に改めることだ。
だが、これを実行するには
- プログラムの大幅な改良
- 過去のデータをすべて変換
- データが増えた分のメモリやディスク容量を確保
サンプル・プログラムの実行例
この対策方法を JavaScriptで実装したプログラムを作ってみた。
「年月日」のテキストボックスにカーソルを乗せると、カレンダー入力ウィンドウが現れる。カレンダー入力してもいいし、テキストボックスから直接、年月日を入力してもいい。
「年月日」のテキストボックスにカーソルを乗せると、カレンダー入力ウィンドウが現れる。カレンダー入力してもいいし、テキストボックスから直接、年月日を入力してもいい。
「年月日」に "1985-04-11" を入力すると、「年(yy)」は "85" に、「年(yyyy)」は "1985" と表示する。
「年月日」に "2025-04-11" を入力すると、「年(yy)」は "25" に、「年(yyyy)」は "2025" と表示する。
ところが、「年月日」に "2050-04-11" を入力すると、「年(yy)」は "50" に、「年(yyyy)」は "1950" と表示してしまう。前述のように、「50」を境に1900年代と2000年代を判定しているので、これは正しい動きだ。
「年月日」に "2025-04-11" を入力すると、「年(yy)」は "25" に、「年(yyyy)」は "2025" と表示する。
ところが、「年月日」に "2050-04-11" を入力すると、「年(yy)」は "50" に、「年(yyyy)」は "1950" と表示してしまう。前述のように、「50」を境に1900年代と2000年代を判定しているので、これは正しい動きだ。
yy2yyyy.html
50: /**
51: * 西暦下2桁を西暦4桁に変換する．
52: * 50未満なら2000年代、50以上なら1900年代に変換する．
53: * @param Number yy 西暦下2桁
54: * @return Number 西暦4桁
55: */
56: function yy2yyyy(yy) {
57: return (yy < 50) ? yy + 2000 : yy + 1900;
58: }
yyをyyyyへ変換するユーザー関数は yy2yyyy_1 だ。if文を使って判定を行っている。
2000年問題の再燃
私を含め、当時、2000年問題に対応した技術者はこう考えていた――次の境界である 2050年が来る前の 2020～2030年頃には、すべての記録が yyyy-mm-dd に改められているに違いない、と。
ところが2025年4月現在、汎用電算機は姿を消し、メモリやディスク容量の制約も大きく緩和されたにもかかわらず、yy-mm-dd で記録するシステムが、意外に残っているのだ。ご利用の業務システムやブログのログ、エクスポートデータを確認してみていただきたい。
2050年まで25年あるとはいえ楽観してはいられない。むしろ、データ量は年々歳々増えているのだから、早いうちに yyyy-mm-dd 形式に改良しないと、データ変換だけでたいへんな作業になってしまう。
その際、Date型 に置き換えるのではなく、インターネット上で標準的に使われているタイムスタンプである ISO 8601 形式に基づいた文字列に置き換えることをおすすめする。Date型 はハードウェアや処理系に依存することが多く、将来、システム移行をする際に、また置換作業が発生するリスクがあるためだ。
せっかく、メモリやディスク容量の制約が緩和されたのだから、西暦が基準である限り利用できるデータ形式で記録しようではありませんか。
ところが2025年4月現在、汎用電算機は姿を消し、メモリやディスク容量の制約も大きく緩和されたにもかかわらず、yy-mm-dd で記録するシステムが、意外に残っているのだ。ご利用の業務システムやブログのログ、エクスポートデータを確認してみていただきたい。
2050年まで25年あるとはいえ楽観してはいられない。むしろ、データ量は年々歳々増えているのだから、早いうちに yyyy-mm-dd 形式に改良しないと、データ変換だけでたいへんな作業になってしまう。
その際、Date型 に置き換えるのではなく、インターネット上で標準的に使われているタイムスタンプである ISO 8601 形式に基づいた文字列に置き換えることをおすすめする。Date型 はハードウェアや処理系に依存することが多く、将来、システム移行をする際に、また置換作業が発生するリスクがあるためだ。
せっかく、メモリやディスク容量の制約が緩和されたのだから、西暦が基準である限り利用できるデータ形式で記録しようではありませんか。
参考サイト
- 「西暦2000年問題」とは：総務省
- 厚生省におけるコンピュータ西暦２０００年問題への取組について：厚生労働省
- タイムスタンプの必要性：ぱふぅ家のホームページ
（この項おわり）
これ以降、西暦年4桁を yyyy、2桁を yy、月の数字2桁を mm、日の数字2桁 dd と表記する。月や日が1桁の時は、頭に 0 を付ける。そして、年月日の間は半角ハイフンを入れたり、更にメモリを節約するために何も入れないようにしていた。たとえば、1985年4月11日なら、"75-04-11" もしくは "750411" という文字列として記録した。