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型の範囲や精度はいずれも実装定義としている。UNIXの標準（POSIX）には「shall be integer or real-floating types.」とのみ記述があり、ビット幅ないし値の範囲については何らの定めも無い。伝統的な実装ではtime_tをintとし、そのintは符号つき32ビットであった。このため最大値は (2 − 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秒、閏秒は考慮していない）を過ぎると、この値がオーバーフローし、負と扱われるため、時刻を正しく扱えていることを前提としたコードがあれば、誤作動する。ある実装における time_t の型を変更することだけであれば、プログラム中のたった1箇所 (typedef) を書き換えるだけであるが、実際の運用では、アプリケーションプログラムにおける時刻の扱い全てが正しくある必要がある。また、すでにあるデータ構造中で32ビット固定長として割り当てられていれば、問題が発生する。たとえば、Linuxのファイルシステムを例に挙げると、ext2、ext3、ReiserFSのタイムスタンプは同日付までしか対応していない。この期日以前でもプログラムで内部的にこの制限を超えた時刻データを扱おうとすれば同様のエラーが発生するため、たとえばちょうど半分を経過した2004年1月11日にはすでにATMの誤作動といったトラブルが発生した。この事例ではプログラム中のある時刻と別の時刻の中間の時刻を求めるような処理で、相加平均を単純に求める formula_1 のような式を利用していたものとみられる（計算機による計算におけるこのような式による、露呈しにくいバグはこの問題に限らず普遍的なものであり、一般に注意を要する）。他にも顕在化していないトラブルが今後表面化するという可能性はあり得る。以下のような理由により、2000年問題より深刻であるという指摘もある。対策としては、time_t型を符号つき64ビット整数型（一般にはlong long int型）にするという方法がある。符号つき64ビット整数型の場合、上限は9,223,372,036,854,775,807 (2 − 1) である。これを秒数に用いるとおよそ西暦3000億年まで使用できるので、事実上問題が発生することはない。最近のオペレーティングシステムや処理系では、time_t型は符号つき64ビット整数型で表されるようになってきている。また、何らかの事情によりtime_tを64ビット化できない環境に対しては、time_tを符号なし32ビット整数型（一般的にはunsigned long int型）にするという回避策が使われることもある。この場合、上限は4,294,967,295 (2 − 1) となり、2106年2月7日6時28分15秒（閏秒を考慮しない場合）まで表現可能になる。従って2038年問題は回避できるが、結局2106年には問題が発生するため、あくまで64ビット化が困難な環境に限って適用すべき方法とされる。Mac OS XではNSDateクラスにて協定世界時の2001年1月1日0時丁度をエポックタイムに更新したため、これを使用している限り、2038年については問題を回避できる。

出典:wikipedia