|
2038年問題（にせんさんじゅうはちねんもんだい）は、2038年1月19日3時14分7秒（UTC、以下同様）を過ぎると、コンピュータが誤動作する可能性があるとされる年問題。 == 経緯 == 時刻の表現として「UNIX時間」《協定世界時における1970年1月1日0時0分0秒からの経過秒数》を使用しているコンピュータ等のシステムがある。この起点の時刻は、最初にUNIXにそのような機能が実装された時にキリがよかった過去の時刻であり、たまたまそう決めたというだけのものに過ぎない。 この経過秒数を表現する型は、現在の標準では、「time_t型」である。C言語の標準である「ISO/IEC 9899:1999」では、time_t型の範囲や精度はいずれも実装定義としている〔"The range and precision of times representable in clock_t and time_t are implementation-defined.", ISO/IEC 9899 7.23.1.4〕。UNIXの標準（POSIX）には「shall be integer or real-floating types.」とのみ記述があり、ビット幅ないし値の範囲については何らの定めも無い。 伝統的な実装ではtime_tをintとし、そのintは符号つき32ビットであった。このため最大値は (231 − 1) = 2,147,483,647 となり、取り扱えるのは2,147,483,647秒（≒ 68年）までに限られていた。これを前提として作成されたプログラムは、協定世界時における1970年1月1日0時0分0秒（日本標準時では1970年1月1日9時0分0秒）から2,147,483,647秒を経過した、2038年1月19日3時14分7秒（日本標準時では2038年1月19日12時14分7秒、閏秒は考慮していない）を過ぎると、この値がオーバーフローし、負と扱われる〔時刻の場合、2038年1月19日3時14分7秒の次は、1901年12月13日20時45分52秒となる。〕ため、時刻を正しく扱えていることを前提としたコードがあれば、誤作動する。 ある実装における time_t の型を変更することだけであれば、プログラム中のたった1箇所 (typedef) を書き換えるだけであるが、実際の運用では、アプリケーションプログラムにおける時刻の扱い全てが正しくある必要がある。また、すでにあるデータ構造中で32ビット固定長として割り当てられていれば、問題が発生する。たとえば、Linuxのファイルシステムを例に挙げると、ext2、ext3、ReiserFSのタイムスタンプは同日付までしか対応していない。 この期日以前でもプログラムで内部的にこの制限を超えた時刻データを扱おうとすれば同様のエラーが発生するため、たとえばちょうど半分を経過した2004年1月11日にはすでにATMの誤作動といったトラブルが発生した〔大和田尚孝「コンピュータの“西暦2038年問題”発生、早くも日本を揺るがす 」日経コンピュータ、2004年2月2日〕。この事例ではプログラム中のある時刻と別の時刻の中間の時刻を求めるような処理で、相加平均を単純に求める のような式を利用していたものとみられる（計算機による計算におけるこのような式による、露呈しにくいバグはこの問題に限らず普遍的なものであり、一般に注意を要する）。他にも顕在化していないトラブルが今後表面化するという可能性はあり得る。 以下のような理由により、2000年問題より深刻であるという指摘もある。 *2000年問題はアプリケーションレベルでの修正が可能であったが、この問題は現在普及しているC言語処理系やOSのAPIといったシステムの深いレイヤに潜む問題である。 *「32ビットの符号付2進表現におけるラップアラウンド」という理由を理解するには、ある程度の専門知識を必要とするので、一般大衆、経営者、政治家などの理解と関心を得にくい可能性がある。 *2000年問題のように暦年の変わり目というキリのよいときに地域の標準時に応じて順次に問題の時刻が世界を巡るのではなく、ごく中途半端な時刻に世界同時に一斉に問題の時刻が訪れるので、もし問題が生じた場合は対応するための人的資源の確保がより困難となる可能性がある。 抄文引用元・出典: フリー百科事典『 ウィキペディア（Wikipedia）』 ■ウィキペディアで「2038年問題」の詳細全文を読む 英語版ウィキペディアに対照対訳語「 Year 2038 problem 」があります。 スポンサード リンク
|