|
Article on other languages:
|
2038年問題(にせんさんじゅうはちねんもんだい)は、2038年1月19日3時14分7秒(UTC)を過ぎると、コンピュータが誤動作する可能性があるとされる問題。
経緯標準的なC言語の実装では、時刻の表現形式として1970年1月1日0時0分0秒(UTC)からの経過秒数[1]を使用している。これはUNIXの仕様に由来するもので、time_t型という。 C言語の規格を定めた「ISO/IEC 9899:1999」では、time_t型の範囲や精度はいずれも処理系依存としているが、[2]time_t型は、伝統的には符号つき32ビット整数(signed long int型)であり、最大値は (231 - 1) = 2,147,483,647 となる。つまり、2,147,483,647秒までしか計算できない。 このようなAPIの下で作られたアプリケーションでは、1970年1月1日0時0分0秒から2,147,483,647秒を経過した、2038年1月19日3時14分7秒を越えると、この値がオーバーフローし、負と扱われるため、誤作動する可能性が高い。さらに、この仕様は他の多くのプログラミング言語でも採用されているため、それらの言語で作られたアプリケーションも同様に誤作動する可能性が高い。 また、ファイルシステムのext2、ext3、ReiserFSのタイムスタンプも同日付までしか対応していない。 ただし、この期日以前でもプログラムで内部的にこの秒数を超えた時刻データを扱おうとすれば同様のエラーが発生するため、2004年1月11日にはすでにATMの誤作動といったトラブルが発生した(プログラム中に現在時刻を2倍する式があったため、2,147,483,647秒の半分以上経過した時点で誤動作が発生した)。他にも顕在化していないトラブルが今後表面化するという可能性はあり得る。 年数の扱い方に問題があった2000年問題はアプリケーションレベルでの修正が可能であったが、この問題は、現在普及しているC言語の処理系の実装にかかわる問題であり、2000年問題より深刻であるという指摘もある。 対策対策としては、time_t型を符号つき64ビット整数型(一般にはlong long int型)にするという方法がある。符号つき64ビット整数型の場合、上限は9,223,372,036,854,775,807(263 - 1)である。 しかし、2038年問題と同じように考えると、292277026596年に桁あふれが起こる可能性があり、これを「292277026596年問題」と呼ぶこともある。ただ、符号つき64ビット整数型は、上記の通り、292277026596年(西暦3000億年近く)まで使用できるので、この問題は宇宙の歴史(推定137億年)の20倍から21倍ほどの時間が経過しないと発生しない。西暦10000年問題と同じく、真面目な話ではなく、一種のジョークとして語られている。 最近のオペレーティングシステムや処理系では、time_t型は符号つき64ビット整数型で表されるようになってきている。 関連した問題
脚注
関連項目外部リンク |
This article is from Wikipedia. All text is available under the terms of the GNU Free Documentation License.
Mercedes Car
This site monitored by SitePinger.net