危機へのカウントダウン



ここでは、主にコンピュータの日付設定に何らかの問題が発生する時までのカウントダウンをしています。(JavaScript)




西暦2001年1月1日
YYMMDD形式の日付のため2000年を1900年とコンピュータが勘違いすることによっていろいろな障害が出るといわれていました。



西暦2030年1月1日
2000年問題を簡単に解決するために、00〜29年までを2000年代、30〜99年までを1900年代と認識させる設定をしたプログラムはこの日を1930年1月1日と判断してエラーを起こします。



西暦2050年1月1日
2000年問題を簡単に解決するために、00〜49年までを2000年代、50〜99年までを1900年代と認識させる設定をしたプログラムはこの日を1950年1月1日と判断してエラーを起こします。



西暦2070年1月1日
2000年問題を簡単に解決するために、00〜69年までを2000年代、70〜99年までを1900年代と認識させる設定をしたプログラムはこの日を1970年1月1日と判断してエラーを起こします。



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



日本時間西暦2106年2月7日15時28分16秒*
C言語は時刻を1970年1月1日0:00を起点に2進法32桁を経過時間(単位 秒)に使う方法もあるそうです。
そのため、起点から4,294,967,295秒たったこの日のこの時間にオーバーフローしてしまいます。



西暦2080年1月1日
2000年問題の対策をするために西暦4桁表示に直したものはいいのですが、中には2桁のままで
80〜99年は1900年代
00〜79年は2000年代
というルールで、対策したものがあります。
この場合、当然ですが2079年12月31日23時59分59秒の次は1980年1月1日0時0分0秒となります。
MS-DOS・Windows が影響を受ける可能性があります。



西暦2100年1月1日
よく携帯電話などは2099年までしかカレンダーが入っていません。
そのため2100年になると、障害が出ます。
まあ、あと95年(これを書いた時点で)ほどあるし、携帯の寿命はせいぜい2年ぐらいなのでそのころには骨董品でしょうが・・・。
因みに、試したところ時計が停止(2099年12月31日23時59分)するものと、電源が落ちて設定が初期化される(00年00月00日--:--)ものがありました。
前者はいいのですが、後者は致命的?



西暦2100年3月1日
今使われている暦では、
4で割り切れる年は閏年。
しかし、100で割り切れてかつ400で割り切れないは平年。
というルールの元運用されています。(数千年たつと、さらにルールが必要になるかもしれませんが)
で、ちょうど2000年はその400年に1回の例外中の例外だったので、いちいちその設定が面倒だから4年に1回閏年のルールだけでいいと考えたプログラマーがいた場合、この日を2月29日と勘違いします。



西暦10000年1月1日
今西暦4桁表示を使用していますがこの日に、表示不能に陥り西暦0年(紀元前1年?)になってしまうでしょう。
まあ、あと8000年もあとのはなしですが・・・。



日本時間西暦292277026596年12月5日0時30分7秒?
JavaScriptがオーバーフローしてしまったので、がんばって手動計算しました。(多倍長電卓をしようして)
たぶん、この日64bit符号付きの日付フォーマット(頭の一桁を±に残りを1970年1月1日0:00からの秒数に当てる)はオーバーフローします。




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



[BACK]

[HOME]