コンピュータの２０００年問題が話題になっている。
コンピュータが暦を認識するときに、初期の機種だとデータの扱いを簡単にするため、１９９９年のように４桁ある数字を「９９」のように下２桁だけで認識していたので、２０００年になった時点で「００」になり、様々な年数・日数の計算が狂ってしまうという問題なのだが、これについては新しいコンピュータだと既に対応しているようだし（私も自分のパソコンの時計の日付を１年進めて、ファイルを保存して試してみたが、問題はないようである）、専門家も力を入れて取り組んでいるようなので、世界中がパニックになるということはないだろうと楽観視している。（素人の考えなので、本当は危険なのかもしれないが‥‥）
ところが、西暦２０００年には、１月１日の他に、もう１つあぶない日があるらしい。
それが、２月２９日だという。
「ん？」と思う方もいるかもしれない。西暦２０００年はオリンピックのある年だから、閏年のはずだ。その２月２９日がどうして危ない日なのだろう‥‥と疑問に思われるだろう。
昔のカレンダーをお持ちの方は（といっても１００年、２００年前のカレンダーを持っている人はいないだろうが）、西暦1700年、1800年、1900年のカレンダーで、２月を見ていただきたい(^^;)
実は、どの年も２月は２８日で終わっているのである。
どうも、１００で割り切れる年は、閏年ではないようなのである。では、西暦2000年はどうなのだろうか？
このことをはっきりさせるには、現在使われているグレゴリオ暦というものについて知らなければならない。
グレゴリオ暦はローマ教皇グレゴリウス１３世の時代、1582年10月15日に採用された。（日本では本能寺の変があった年である）
それ以前は、ユリウス暦が使われていた。
一般的に１年は365日とされているが、天文学的には正確に観測すると365.24219879日である。
ユリウス暦は、通常は1年を365日とし、4年に1度の閏年には1年を366日にする。この閏年の効果によって、長期的にはユリウス暦の1年は365.2500日となり、1太陽年より11分14秒長い。この太陽年とのずれが128年間で1日に達する。ずれが累積した結果、16世紀初頭には春分が3月11日になってしまっていた。
このずれを是正するために採用されたのがグレゴリオ暦で、１太陽年が365.24219879日であるという正確な観測に基づき、平年を365日、閏年を366日と定め、閏年を400年に97回置くことにした。
閏年は普通、4で割り切れる年（現在では夏季オリンピック開催の年）であるが、400年に３回例外を設けている。
つまり
１） 普通は４で割り切れる年が閏年なのだが、
２） １００で割り切れる年は閏年でない。
３） しかし、４００で割り切れる年は特別に閏年とする。
というのがグレゴリオ暦のきまりである。
近年では、1700年、1800年、1900年が閏年ではなかった。来る2000年は閏年である。
ちなみにこの方法でも、若干の誤差は出るのだが、それを修正するためには、約3300年に１日の修正を加えるだけでよいという。
したがって、西暦2000年については、何も知らない人（レベル１）は閏年だと思うだろうし、少しだけモノを知っている人（レベル２）は閏年ではないと言うだろうし、本当に知っている人（レベル３）は閏年だと断言できるということになる。
そこで、２月２９日が、コンピュータの新たな問題になってくるのだ。
おそらく、1900年の２月については、「１００で割り切れる年は閏年ではない」ということで、２月２８日で終わる処理がされているはずだ。しかし、西暦2000年についてはどういう処理をしているのだろうか。
実は、私も、この文章を書くために、検索エンジン等で「閏年」について調べてみた。そうしたら、かなり興味深いことがわかった。
いくつかのコンピュータ・メーカーでは、すでにこの問題に注目し、自社のコンピュータで実験した結果を公表している。すると、中には、この問題に対応していない例も出ていた。つまり、西暦2000年の２月２９日（実際に存在する）を、３月１日と認識してしまうことがあるようなのである。
私も自分のパソコンで、カレンダーの日付を2000年にして２月を見てみた。すると、ちゃんと２９日まである。では、1900年や2100年（どちらも閏年ではない）の２月はどうかと試してみたが、これは、その年にまで変更することができず、実験不能であった。
まあ、今使っているパソコンが2100年まで使えることはないだろうから、直接の問題はないかもしれないが、表計算ソフトなどで日数計算をする場合には誤差が出てくることも考えられる。個人レベルの使用ならそれほど問題はないかもしれないが、ものすごく遠くまでロケットを飛ばすなどという計算をする場合には問題だろう(^^;)
前述したように、私が「閏年」について、検索エンジンで調べてみたら、けっこう、この問題については触れているところも多いので、既に諸機関では対応を考えているのだろうが、私にとっては今まで知らなかったことなので、読んでくださる方の何かの参考にでもなればと思い、長々と書いてみた次第である(^^;)
と、このような文章を書いて、ホームページにアップしたあとで、私の知人に２０００年問題について更にたずねてみた。
この方は、現在、２０００年問題について、企業や自治体の相談役としてアドバイスをしている人で、コンピュータについては完全なプロの人である。
すると、まだ次のような「危ない日」があるということを教えてもらった。
危ない日
説 明
私の感想(^^;)
1999/08/22
GPSシステムがリセットされる日
(カーナビ、タクシーなど)
料金メーターが０円に
なるかな。方向オンチ
の私の頭のナビは常に
リセット状態です(^^;)
1999/09/09
COBOL言語によるプログラムの問題
コボル君も999で大フィ
ーバー！
1999/12/31
締めの業務中に日付が2000/1/1に変わった場合
大晦日は仕事をしない
で、紅白を見て寝まし
ょう！
2000/01/01
Y2Kそのもの
やはり、これが王様で
しょう(^^;)
専門用語では、2000年
のことを｢Y2K｣って言う
んですね。ちなみにYKK
はファスナーです(^^;)
2000/02/28
締業務が行われては大変
しめしめ！
2000/02/29
閏年
(未対応の場合、存在しない日付で以降曜日もズレる)
この日が日曜だったら
よかったのですが、実
は火曜日です。
2000/03/01
同上
うーむ‥‥
英語でマーチ、日本語
でワルツ‥ってことは
ないか(^^)弥生ですね
2038/01/18
UNIXが使えなくなる日(仕様です)
なんか使用期間限定の
お試しソフトっぽいで
すねぇ。
2100/01/01
MS-DOS(FAT16)が使えなくなる日(そこまで使う人は
いないでしょうが、これも仕様です)
その頃のMD-DOSのバー
ジョンは、いくつにな
っているかな？
やっぱり｢６｣でしょう
か(^^;)
これらは、業務用アプリケーションで考えられる問題とのことだが、その手のコンピュータやアプリケーションは、かなり古いものも、まだ現役で頑張っていたりするから、このまま放っておいたら、現実に多くのトラブルが起きるのかもしれない。
また、２０００年からは「成人の日」と「体育の日」も、これまでのように期日指定型でなく、曜日に対応したものになるので、従来の休日判定ルーチンを使っていると誤動作のもとになるとのこと。（まあ、日本で作ったアプリケーション限定の問題だろうが）
こういうことを全て考慮して、プログラムの対応を考えていくとなると、コンピュータ技術者の人も本当に大変である。
２００１年から導入されることがほぼ決定的な「サマータイム」への対応も、素人考えでは、けっこう面倒なような気もする。コンピュータ内の時計のリセットなどはどうするのだろうか。個人使用のパソコンなら手動でやればよいが、企業や学校など多くのコンピュータを使っているところはどうするのだろうか。また、サマータイムから平常の時間に移る日（１日が２５時間になる）あたりの時間処理はどうなるのだろう。（欧米では行われているので、ノウハウはあると思うのだが）
こういうことを考えていくと、夜も眠られなくなりそうだが、睡眠不足になってもしょうがないので、寝てしまうことにしよう。（睡眠中に閏時間でもあってくれると嬉しいのだが‥‥）
ホームページに戻る
前のページへ