「2038年問題」の版間の差分
削除された内容 追加された内容
31行目:
*時刻aと時刻bのちょうど中間の時刻を求めたい時、それぞれのUnixタイムをTaとTbとして、(Ta+Tb)/2 のように計算すると、2038年問題の半分以降が経過していればTa+Tbの計算で[[算術オーバーフロー|オーバーフロー]]し、間違った結果になる。これは1,073,741,824秒目であり、2004年1月10日13時37分4秒以降がこの場合に相当する（実際に2004年1月10日乃至11日に、そのようにして起きたものと思われるトラブルの報告があった<ref>
「[http://itpro.nikkeibp.co.jp/members/NC/ITARTICLE/20040325/1/ 「西暦2038年問題」でトラブル相次ぐ]」[[日経コンピュータ]]、2004年4月1日</ref>）。
== 類似する年問題 ==
*[[2001年9月9日問題]]は、2001年9月9日にtime_t型の値が9億秒から10億秒と桁が増えることに伴う問題。time_t型の値を文字列（辞書順）でソートしていたことで、「9億 > 10億」と判断され、項目の新旧が正しく判断されない問題（新しく作られた項目が表示されない、古いものとみなされ削除されるなど）が発生した。
*[[Network Time Protocol|NTP]]など、1900年1月1日からの積算秒数で時間を表現するシステムもあり、符号なし32ビットの値が[[2036年]][[2月7日]]6時28分15秒 (UTC) を超えるとオーバーフローすることによって問題が発生する（→[[Network Time Protocol#2036年問題|2036年問題]]）。[[Simple Network Time Protocol|SNTPv4]]を定めた<nowiki/>RFC 4330<nowiki/>には、最上位ビットが0の場合は時刻が2036年から2104年の間であるとみなして、2036年2月7日6時28分16秒 (UTC) を起点として計算することで2036年問題を回避する方法が書かれている。
*2038年4月23日問題 - [[ユリウス通日]]を内部日付表現に用いる物のうち、基準日（[[グレゴリオ暦|グレゴリオ歴]]1858年11月17日正午）からの修正ユリウス日（MJD）を使用し、かつ16ビットで処理しているシステムでは、日数が16ビットからあふれるために問題が起こる。
* 2038年11月21日問題 - GPSは内部処理で週数を10ビットで管理しており、起点である1980年1月6日から3072週後にあふれて0に戻る。（10ビットでは3回目）
== 脚注 ==
| |||