(cache)2038年問題へのカウントダウン

2038年問題カウントダウン時計

世界標準時:2038年1月19日3時14分8秒(日本時間:12時14分8秒)

C言語は通常時刻を1970年1月1日0:00を起点に2進数で頭の一桁を±に残り31桁を経過時間（単位　秒）の計32桁で表しています。
そのため、起点から2,147,483,647秒たったこの日のこの時間以降に値がおかしくなり（1900年）エラーが起こる可能性があります。
因みに、2004年1月、ATMにこれを原因とする障害が発生しました。

--詳しい説明--

C言語で時間は1970年元日0時からの経過秒数を符号付32bitで表します。
符号付32bitだと一番上の桁を±に使用する（＋なら0、－なら1）ため

10000000000000000000000000000000	0x80000000	-2147483648
10000000000000000000000000000001	0x80000001	-2147483647
（略）
11111111111111111111111111111101	0xFFFFFFFD	-3
11111111111111111111111111111110	0xFFFFFFFE	-2
11111111111111111111111111111111	0xFFFFFFFF	-1
00000000000000000000000000000000	0x00000000	0
00000000000000000000000000000001	0x00000001	1
00000000000000000000000000000010	0x00000002	2
00000000000000000000000000000011	0x00000003	3
（略）
01111111111111111111111111111110	0x7FFFFFFE	2147483646
01111111111111111111111111111111	0x7FFFFFFF	2147483647

と、表現されます。
表から分かるように、2147483647より1大きい数は、オーバーフロー（桁あふれ）して-2147483648となります。
つまり、1970年元日0時から2147483648秒たった時間は、1970年元日0時より2147483648秒前の時間と判定されてしまいます。
1970年元日0時から2147483648秒経った時間は世界標準時:2038年1月19日3時14分8秒(日本時間:12時14分8秒)、2147483648秒戻った時間は世界標準時:1901年12月13日20時45分52秒(日本時間:翌日5時45分52秒) と、実に差が130年以上あります。
そのため、コンピュータが日付を正しく認識しなくなり、何らかの不具合を起こす可能性があります。
例えば、データを日付順に並べる場合、振り切れて以降の時間は振り切れる前の時間より古いと認識され、順番が狂ったり、古いと判断して削除したり、利子計算を間違って預金や借金を130年分の利子分引いたりするかもしれません。
さらに、システムが異常を感知してダウンしたりするかもしれません。
また、時間を扱う計算の途中で値が2147483647を超えた場合も、計算が途中で狂うため不具合が起きる可能性があります。実際銀行のATMがこれを原因とする不具合でダウンしました。（ちょうどその時オーバーフローする値の半分を過ぎ、また計算式の中に値を2倍する箇所があったため）
まだまだあと34年もありますが、ソースの流用を繰り返したりして34年後まで問題が残る可能性も結構あります。複雑なプログラムだと予期しないことが発生し大変なことになるかもしれません。
果たして、問題は回避されるのでしょうか？自分の予想では2000年問題と同じようにギリギリになって慌てる気がします。

--回避方法--

回避方法としては、時間データを64bit符号付整数で表すのが効果的です。
64bit符号付整数は、頭の1桁を±に使用し残り63桁で数値を表します。
つまり-9223372036854775808～9223372036854775807まで扱うことが出来ます。
時間で言うと上限は世界標準時間:西暦292,277,026,596年12月4日15時30分7秒（日本時間翌日0時30分7秒）なので、3000億年近くは問題なく使えます。

その時間の前後のキャプチャー

before

after

※ローカルサーバーを使用。Afterでは2038年問題が原因と思われるエラーが発生してしまいました。

*・・・障害が起こる直前の値

[BACK]

[HOME]

Crisis Counter Ver.1.11
(C)Sunpillar 2004,2005
Last Modified: Tue Jan 14 2020 22:31:34 JST