少し前にPCの西暦2000年問題があったのは覚えていると思う。
何とか重大な被害も出すことなく過ぎ去っていった。知ってると思うが2000年問題は西暦をメモリーをけちって4桁で表すところを2桁で表していた。直すには該当部分のプログラムをプログラマが直せた。しかし2038年問題はそう簡単にはいかない。現在のほとんどのアプリケーションはC言語で書いてある。そのC言語の時間を表すのには「time」関数を使い、そこから得られる秒数を格納するのに「time_t」型の変数を使う。その変数はlong型の整数と定められている。long型の整数とは符号付きで32ビットを2進数で表すものである。しかし符号に1ビット取られるので、実際は31ビットの2進数で表す。C言語の仕様上、時間のデータは全て「秒」で認識している。基準日時が「1970年00:00:00」であり、現在の時刻はこの基準日時から経過した秒数を計算して出している。31ビットの2進数で表すことの出来る秒数は2の31乗で2147483647秒であり、それは約68年になる。その結果正常に時刻を計算出来るのは2038年1月19日までとなる。まだあと何十年もあるじゃないかと思うかもしれないが、そう簡単にはいかない。これは言語の使用なので、勝手にプログラマが書き換えるわけにもいかない。現在考えられている回避策は、long型をlong long型にし、64ビットにすることだ。そうすれば2922億年までもつ。しかし型を変えてしまうと、前に使っていたシステムとの整合が取れなくなってしまうので、かなり無理がある方法だろう。他にはlong型をunsigned long型にすることだ。これは符号無し32ビット整数と言い、32ビット全てを使うことが出来る。そうすると2106年までは持つことになる。しかしこの方法は一時しのぎに過ぎない。結局現在まだ効果的な解決方法は見つかっていない。また2038年まで同じシステムを使うこと何てないだろうと思うかもしれないが、銀行などの巨大なシステムはもうかなり前に書かれたプログラムをちょこちょこ手を加えたりして動かしている。従って2038年にも使われている可能性は非常に高いと言えるだろう。2000年問題より遙かに困難な問題が2038年問題なのである。34年後までには解決されていることを願う。
このエントリーのトラックバックURL:
http://mojya.s8.xrea.com/x/mt/mt-tb.cgi/8
Sun | Mon | Tue | Wed | Thu | Fri | Sat |
---|---|---|---|---|---|---|
1 | 2 | 3 | 4 | 5 | 6 | 7 |
8 | 9 | 10 | 11 | 12 | 13 | 14 |
15 | 16 | 17 | 18 | 19 | 20 | 21 |
22 | 23 | 24 | 25 | 26 | 27 | 28 |
29 | 30 |