- バックアップ一覧
- 差分 を表示
- 現在との差分 を表示
- ソース を表示
- コンピュータ2000年問題 へ行く。
- 1 (2008-12-10 (水) 11:21:58)
- 2 (2008-12-10 (水) 23:05:33)
- 3 (2008-12-13 (土) 11:02:03)
- 4 (2009-02-18 (水) 00:41:50)
- 5 (2009-06-13 (土) 06:38:01)
- 6 (2010-05-01 (土) 11:38:21)
- 7 (2010-05-02 (日) 09:02:43)
- 8 (2010-05-07 (金) 20:29:41)
- 9 (2010-11-02 (火) 22:40:20)
- 10 (2011-08-11 (木) 06:58:38)
- 11 (2012-09-17 (月) 06:44:16)
- 12 (2014-03-22 (土) 15:29:42)
- 13 (2014-12-20 (土) 08:49:14)
- 14 (2017-03-09 (木) 19:47:57)
- 15 (2017-03-10 (金) 02:53:16)
- 16 (2017-03-10 (金) 18:05:50)
- 17 (2017-03-11 (土) 16:07:11)
- 18 (2017-04-10 (月) 14:19:12)
- 19 (2017-04-12 (水) 00:12:48)
- 20 (2017-04-12 (水) 17:58:18)
- 21 (2017-08-17 (木) 21:04:26)
- 22 (2020-12-13 (日) 12:20:30)
- 23 (2021-03-12 (金) 11:56:54)
- 24 (2021-03-13 (土) 09:15:37)
- 25 (2021-08-12 (木) 18:15:09)
- 26 (2022-01-14 (金) 22:13:54)
- 27 (2022-01-15 (土) 07:02:40)
- 28 (2022-02-16 (水) 09:30:53)
- 29 (2022-02-17 (木) 17:39:57)
- 30 (2022-11-03 (木) 06:45:19)
- 31 (2023-02-09 (木) 13:15:18)
- 32 (2023-02-25 (土) 12:06:22)
- 33 (2024-03-09 (土) 16:46:43)
【コンピュータ2000年問題】 †
1990年代末期から世界各地で顕在化した技術的問題。
西暦1999年末日から2000年元旦にかけて世界中のコンピュータが一斉に誤作動するという危惧。
概要 †
黎明期のコンピュータは、日付を扱う際に「年」を西暦の下2桁のみで表現するのが一般的であった。
この仕様は当時の技術的限界によるものだったが、技術上の問題が克服された以降も慣習的に2桁表記が続いていた。
だが、年号を2桁の数で表現すると、西暦2000年を示す「00」を西暦1900年と誤認する可能性がある。
純機械的には単純なトラブルだが、これが全世界のあらゆる端末で同時並行的に生じた時に実社会に何を引き起こすかは未知であった。
このため、考え得る最悪の事態に対する警鐘が何度となく指摘され、重篤な社会的混乱を避けるための確認と修正が全世界規模で行われた。
技術的背景 †
何故、たかが4桁の数字を2桁まで省略しなければならなかったのか?
答えは、その2桁の差が、かつてのコンピュータ科学における重大な課題であったからだ。
コンピュータの計算は、多数の『ビット』を機械的に操作する事によって処理されている。
1個の『ビット』は論理的には一桁の二進数(0/1)であり、物理的には電気回路のスイッチ(ON/OFF)である。
そして、コンピュータのCPU(中央処理装置)が1回の演算で操作できるビットの数は有限である。
1980年代に存在した端末の大半は、一度に8ビットまでしか制御できなかった。
つまり、数値が8ビットで表現できる数(0〜255)である事が保証されていないと、あらゆる操作・演算の所要時間が2倍以上に増えるのだ。
これに加えて計算内容を記憶するメモリも極めて限られていたため、データの節約は死活問題だった。
例えば、任天堂の「ファミリーコンピュータ(1983年)」は作業用の記憶領域を2キロバイト持っていた。
1バイトは8ビットで構成されるので、つまり2桁の数値2000種類、または4桁の数字1000種類で完全にメモリを使い果たす。
不用意に数字の桁数を増やすような余裕がなかった事は疑いない。
1990年代には、32ビットを制御できるCPUと1メガバイト以上の一時記憶装置が登場していた。
つまり日付の年数を正規の西暦表記に変える事が可能になっていたのだが、慣習的に2桁での表記が続いていた。
実際、日付の表記方法を変えるとなれば、当時存在していたほぼ全てのコンピュータが仕様変更や機種交換を余儀なくされる。
今日の高度情報社会の基盤となるコンピュータシステムは当時すでに普及しており、既存の端末の数はすでに膨大であった。
事前に予想されていた通り、これらの確認・修正作業は困難を極めた。
完全に修正不可能になっていたためゼロから新規設計でシステムを構築し直すしかなかった事例も少なくない。
稼働開始から10年・20年も経てば、開発当時の技術者が社内に一人もいなくなっていても驚くには値しない。
航空・軍事分野に関連する問題点 †
…等々。
その後 †
1999年12月31日〜2000年1月1日にかけて、公共交通機関が日付をまたぐ運行を自粛するなどして不測の事態に備えていた。
実際に2000年になった際、一部の機械に小さなトラブルが出たものはあったが、重篤な被害には至らなかった。
結果として、この問題は人類史上において特筆に値する出来事には発展せず、いわゆる「世紀末カルト」の一種として急速に忘れ去られつつある。
当時のコンピュータ技術者たちがどのような問題を検知し、どのような対策を採っていたかについて全貌は明らかでない。
そして、今となっては調べるのも容易ではない。
とはいえ、2000年代になってから以後も類似の問題は(局地的ながら)たびたび生じている。
コンピュータの誤作動にまつわる問題は「2000年問題」という枠を越えていつでも起こり得る普遍的な現象と化しつつあるのが現状である。
類例 †
- 閏年
- グレゴリオ暦では「西暦の数字が4で割り切れる」「西暦の数字が100及び400で割り切れる」年を「閏年」とするが、「100で割り切れるが400で割り切れない年」は閏年としない。
この日付処理について誤解したままプログラムが実装された結果、各所でトラブルが生じた事がある。 - 原子時計の桁あふれ
- 全地球測位装置(GPS)に用いられるナブスター衛星に搭載の原子時計は、年・月・日・時・分の概念を使わず、週と秒の概念だけで時刻を表現している(なお、この「時間」は1980年1月6日を基準に、海軍天文台の観測成果を加味して時刻を刻んでいる)。
このうち「週」には10ビット(0〜1023)しか割り当てられておらず、1024週ごと(1999年8月21日と2019年4月7日)に桁あふれを起こして0週目に戻っていた。
なお、現行最新のGPSは「週」に13ビット(0〜8191)を割り当てる規格に更新されており、2137年までは桁あふれを起こさない。 - UNIX内部時計
- 業務用システムとして使われるUNIX系列のソフトウェアでは、時刻を1970年1月1日0時0分0秒(協定世界時)からの経過秒数で表現している。
古いシステムではこの時刻表現に32ビットを割り当てており、その種のシステムでは2038年1月19日3時14分7秒(同上)に桁あふれを起こす。
現行端末のほとんどは時刻表現に64ビットを割り当てており、2262年4月11日までは桁あふれを起こさない。