2000年問題など


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

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

1999年7の月
恐怖の大王が降りてきて、地球滅亡。
大陰暦(だとおもったけど違うかも?)では8月にあたり、GPSの問題がそうだとか、核戦争だとかいろいろ....

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

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

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

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

・BIOS
古いパソコン(AT互換機)のマザーボードのBIOSに問題がある場合が有ります。
1999年12月31日の次が1980年1月3日になってしまうということだったと思います。
一時期は騒がれたのですが、まったくといっていいほど聞かなくなりました。
最近のパソコンならまず大丈夫なので、たいした問題ではないということでしょう。
古いコンピュータを扱ってる人は注意しましょう。
特にサーバかなんかにしてたりすると、問題かもしれません。

それと、関係ないですが、NECのPC9821A−MATEの第2世代(As2/Ap2)には、
2000年に関係なく、毎年、年越しできないという致命的なバグが有ります。(^^;)
初代A−MATEを修理に出した場合も、第2世代のBIOSに置き換わる場合が有るので注意が必要です。(なんだかなぁー)
電源を入れた状態での年越しは可能なので、年越しのときには電源を入れてあげましょう。あ、閏年も。
MS−DOS用(Win3.1含む)の対応パッチが出されましたが、一層バグバグになるというとんでもない代物です。
このパッチを使ってはいけません。

・閏年
2000年は2月29日がある閏年です。
閏年の定義は
  • 西暦4桁を400で割り切れる年は閏年である。
  • 西暦4桁を100で割り切れる年は閏年ではない。
  • 西暦4桁を4で割り切れる年は閏年である。
です。
(これはあくまで便宜上の定義です。厳密にはぜんぜん違うので、詳細を知りたい方はちゃんとした文献なりWebを調べてください。)
4で割り切れたらという手抜き処理ならいいのですが、100でとかやってる場合には、400の処理が有るか注意しましょう。

2001年9月9日10時46分40秒(JST) 1時46分40秒(GMT)
プログラム的な話になりますが、UNIXでは時間を1970年1月1日9時0分0秒(日本の場合)からの通算秒で管理されることがあります。
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
これを見ればわかるように、2001年9月9日に桁が変わります。
前回桁が変わったのが1973年なので、それ以降はずっと9桁が続いていました。
というわけで、9桁を前提にしたプログラムをしてしまうと問題が発生します。
桁あふれでプログラムがとまったり、1970年に戻されたり、日付ソート結果で1970年として古い側に回ったり。。

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

2038年1月19日12時14分7秒(JST) 3時14分7秒(GMT)
プログラム的な話になりますが、UNIXでは時間を表す型として、time_t型を使うことが多くあります。
time_t型は実際にはlong型(32ビット)として定義されています。
time_t型とはどういう意味を持つかというと、1970年1月1日9時0分0秒(日本の場合)からの通算秒と定義されています。
ですから1999年とかはかなり大きな値となっています。
そして、32ビットで表すことができる限界が2038年1月19日12時14分7秒ということです。
これの解決としては、OSを64ビット化して、関連モジュールを全部コンパイルし直しするひか手が無いでしょう。
long型は「少なくとも32ビット」と定義されているので、OSが64ビット化されれば拡張されるでしょう。
まだまだ先の話と思われるかもしれませんが、一応知っておくべき問題だと思います。
2000年問題は、パソコンとかに詳しくない一般の人でも理解できると思いますが、この問題は説明に苦労することでしょう。
まあ、30数年も先の話なんで、そのころにはとっくにOSも入れ替わってると思われるので、問題にはならないかもしれませんが。
もし旧システムのまま使いつづけた場合、この問題を上に伝えるのは相当苦労するかもしれません。
OS入れ替えとテストしなおしとなると、かなりの工数がかかるでしょう。
(これはUNIX固有の問題だと思います。でもサーバ系ってUNIXが多いですよね...)

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

2070年
2050年と同じです。
50年じゃなくて70年を境にした場合はこっちだというだけです。
なぜ、2070年かというと、プログラムでは1970年が基準になることが多いので、その100年後ということです。


戻る。