２０００年問題など

２０００年問題だとか９９年問題だとかいろいろ騒がれるようになったので、 有名なものからマイナーなものまであげてみました。

１９９９年

西暦の２桁で扱う古いシステムなどにおいて、９９という値を、９９年ではなく、「データの終わり」とか「データ未設定」といった 本来の西暦とは別に扱ってしまい、正しく入力できない問題がある可能性が有ります。
９９年１月１日、９９年９月９日、９９年１２月３１日などが特に問題となる可能性があります。

１９９９年７の月

恐怖の大王が降りてきて、地球滅亡。
大陰暦（だとおもったけど違うかも？）では８月にあたり、ＧＰＳの問題がそうだとか、核戦争だとかいろいろ....

１９９９年８月２２日

アメリカの衛星であるＧＰＳの日付管理の問題が有ります。
そもそもＧＰＳの日付管理は１０ビット、１０２４週で管理されていて、１９８０年１月６日スタートから数えると、 １９９９年８月２２日がまずいということです。１０２４週になってしまうわけで、リセットされてしまうんですね。
End of Weekとか呼ばれるらしいです。
それで何がまずいかというと、良く言われるのは、ＧＰＳは軍事衛星なんでミサイルの誤発射とかなんとか。
その辺は当然対策済みで、あるわけねーだろって感じです。一般人には関係ありません。
一般人に関係あるのは、古いカーナビゲーションシステムが１９９９年８月２２日以降に使えなくなるということです。
carrozzeriaなんかでは、新聞に広告出したり、ユーザにＤＭ出したりして、無償修理を行っています。

２０００年

今更解説の必要が無いと思われる２０００年問題ですが、忘れられがちなのが２０００年問題というのは１つではなということです。

・西暦２桁

西暦を２桁で扱うシステムで、００をコンピュータが１９００年と認識してしまい、２０００年の予約とかができないことを言います。
99/12/01〜00/01/31 とかやっても 1999/12/01〜1900/01/31 となってしまい、日付の大小関係が狂ってるので不正な値としてなってしまいます。
対応方法としては有名なのが、50年以降は１９００年代、４９年以下は２０００年代と勝手に振り分けてしまう方法です。
４桁に拡張すると、いろいろと手直しが必要で大変なので、応急処置というやりかたです。
これだけの作業でも、企業の基幹システムなどでは大変な作業になります。
対応が遅れるとどうにもならなくなりますが、お金と人手がすごくかかります。中小企業では重大な問題です。
また、入出力の問題だけでなく、データベースの並び替えにも問題が発生する場合が有ります。
日付順に並べるときに、00/01/01 は 99/01/01 よりも古いと認識され、データの一番下になってしまうなどが考えられます。

この２０００年問題はｙ２ｋと書かれたりします。
アメリカなんかでは２０００年問題の対応状況を情報公開しなければいけないみたいです。

・ＢＩＯＳ

古いパソコン（ＡＴ互換機）のマザーボードのＢＩＯＳに問題がある場合が有ります。
１９９９年１２月３１日の次が１９８０年１月３日になってしまうということだったと思います。
一時期は騒がれたのですが、まったくといっていいほど聞かなくなりました。
最近のパソコンならまず大丈夫なので、たいした問題ではないということでしょう。
古いコンピュータを扱ってる人は注意しましょう。
特にサーバかなんかにしてたりすると、問題かもしれません。

それと、関係ないですが、ＮＥＣのＰＣ９８２１Ａ−ＭＡＴＥの第２世代（Ａｓ２／Ａｐ２）には、
２０００年に関係なく、毎年、年越しできないという致命的なバグが有ります。(^^;)
初代Ａ−ＭＡＴＥを修理に出した場合も、第２世代のＢＩＯＳに置き換わる場合が有るので注意が必要です。（なんだかなぁー）
電源を入れた状態での年越しは可能なので、年越しのときには電源を入れてあげましょう。あ、閏年も。
ＭＳ−ＤＯＳ用(Win3.1含む）の対応パッチが出されましたが、一層バグバグになるというとんでもない代物です。
このパッチを使ってはいけません。

・閏年

２０００年は２月２９日がある閏年です。
閏年の定義は

• 西暦４桁を４００で割り切れる年は閏年である。
• 西暦４桁を１００で割り切れる年は閏年ではない。
• 西暦４桁を４で割り切れる年は閏年である。

です。
（これはあくまで便宜上の定義です。厳密にはぜんぜん違うので、詳細を知りたい方はちゃんとした文献なりＷｅｂを調べてください。）
４で割り切れたらという手抜き処理ならいいのですが、１００でとかやってる場合には、４００の処理が有るか注意しましょう。

２００１年９月９日１０時４６分４０秒（ＪＳＴ）　１時４６分４０秒（ＧＭＴ）

プログラム的な話になりますが、UNIXでは時間を１９７０年１月１日９時０分０秒（日本の場合）からの通算秒で管理されることがあります。

1970/01/01 09:00:00　　0
1973/03/03 18:46:40　　100000000
2001/08/18 00:32:29　　998062349
2001/09/09 10:46:40　　1000000000
2038/01/19 12:14:07　　2147483647

これを見ればわかるように、２００１年９月９日に桁が変わります。
前回桁が変わったのが1973年なので、それ以降はずっと９桁が続いていました。
というわけで、９桁を前提にしたプログラムをしてしまうと問題が発生します。
桁あふれでプログラムがとまったり、1970年に戻されたり、日付ソート結果で１９７０年として古い側に回ったり。。

ところで、某マ社のW*ndowsMeのバグ2001 年 9 月 8 日よりも後の復元ポイントが利用できない って。。。

２０３８年１月１９日１２時１４分７秒（ＪＳＴ）　３時１４分７秒（ＧＭＴ）

プログラム的な話になりますが、UNIXでは時間を表す型として、time_t型を使うことが多くあります。
time_t型は実際にはlong型（３２ビット）として定義されています。
time_t型とはどういう意味を持つかというと、１９７０年１月１日９時０分０秒（日本の場合）からの通算秒と定義されています。
ですから１９９９年とかはかなり大きな値となっています。
そして、３２ビットで表すことができる限界が２０３８年１月１９日１２時１４分７秒ということです。
これの解決としては、ＯＳを６４ビット化して、関連モジュールを全部コンパイルし直しするひか手が無いでしょう。
long型は「少なくとも３２ビット」と定義されているので、ＯＳが６４ビット化されれば拡張されるでしょう。
まだまだ先の話と思われるかもしれませんが、一応知っておくべき問題だと思います。
２０００年問題は、パソコンとかに詳しくない一般の人でも理解できると思いますが、この問題は説明に苦労することでしょう。
まあ、３０数年も先の話なんで、そのころにはとっくにＯＳも入れ替わってると思われるので、問題にはならないかもしれませんが。
もし旧システムのまま使いつづけた場合、この問題を上に伝えるのは相当苦労するかもしれません。
ＯＳ入れ替えとテストしなおしとなると、かなりの工数がかかるでしょう。
（これはＵＮＩＸ固有の問題だと思います。でもサーバ系ってＵＮＩＸが多いですよね...）

２０５０年

２０００年問題を２桁で扱った時に、５０年を境に１９００年代と２０００年代を振り分ける場合が有ります。
当然そのようなシステムでは２０５０年頃には再び対応が必要です。
２０５０年まで大丈夫かというとそうではありません。予約システムなどでは未来の日付も必要になるので、事前準備が必要です。
２０００年問題を５０年を境にした対応で扱うようなものは、今の時点でも古いシステムといえるでしょう。
それをあと５０年も使いつづけるともおもえませんけどね。

２０７０年

２０５０年と同じです。
５０年じゃなくて７０年を境にした場合はこっちだというだけです。
なぜ、２０７０年かというと、プログラムでは１９７０年が基準になることが多いので、その１００年後ということです。