2038年問題 （にせんさんじゅうはちねんもんだい）は、協定世界時 （UTC）2038年 1月19日 3時14分7秒（日本標準時 の場合、1月19日12時14分7秒）を過ぎると、コンピュータ が誤動作する可能性があるとされる年問題 。
上から、2進・十進・問題のある時刻・正しい時刻。（GIFアニメ ）3時14分7秒を超えたところで負の値となり、時刻に狂いが生じる恐れがある。 コンピュータおよびコンピュータプログラム における時刻 の表現として「UNIX時間 」《協定世界時 における1970年1月1日0時0分0秒からの経過秒数[ 注釈 1]
UNIX およびUNIX派生のオペレーティングシステム (OS) における基幹ソフトウェア部品 の多くはC言語 で書かれているが、前述の経過秒数を表現する型は、現在の標準では、「time_t 型」である。C言語 の標準である「ISO/IEC 9899:1999」では、time_t型の範囲や精度はいずれも実装定義としている[ 1] POSIX ) には「shall be integer or real-floating types.」とのみ記述があり、ビット幅および値の範囲については何らの定めも無い。
伝統的な実装ではtime_tをintまたはlongのtypedef による型エイリアス（別名）とし、その型は符号付き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秒、閏秒 は考慮していない）を過ぎると、この値がオーバーフロー し[ 注釈 2]
ある実装におけるtime_tの型を変更することだけであれば、プログラム中のたった1箇所 (typedef ) を書き換えるだけであるが、実際の運用では、アプリケーションプログラムにおける時刻の扱い全てが正しくある必要がある。また、すでにあるデータ構造中で32ビット固定長として割り当てられていれば、問題が発生する。たとえば、Linuxのファイルシステム であるext2 ・ext3 ・ReiserFS のタイムスタンプ は同日付までしか対応していない。
この期日以前でもプログラムで内部的にこの制限を超えた時刻データを扱おうとすれば同様のエラーが発生するため、たとえばちょうど半分を経過した2004年1月11日にはすでにATM の誤動作といったトラブルが発生した[ 2] 平均 を単純に求める
(
t
1
+
t
2
)
/
2
{\displaystyle (t_{1}+t_{2})/2}
[ 注釈 3]
2000年問題 はアプリケーションレベルでの修正が可能であったが、この問題は現在普及しているC言語処理系 やOSのAPIといったシステムの深い層に潜む問題であるため、2000年問題より深刻であるという指摘もある[ 3]
対策としては、time_t型を符号付き64ビット整数型（一般にはlong long int型[ 注釈 4] オペレーティングシステム や処理系 では、time_t型は符号付き64ビット整数型で表されるようになってきている。UNIXベースのOSでは、64ビット版でtime_tも併せて64ビット化されることが多い。
何らかの事情によりtime_tを64ビット化できない環境に対しては、time_tを符号無し32ビット整数型（一般的にはunsigned long int型2106年 2月7日6時28分15秒（閏秒を考慮しない場合）まで表現可能になる。従って2038年問題は回避できるが、結局2106年には問題が発生するため、あくまで64ビット化が困難な環境に限って適用すべき方法とされる。
macOS (Mac OS X 10.0) ではNSDateクラスにて協定世界時 の2001年1月1日0時ちょうどをエポックタイムとして刷新し[ 4] [ 5] 倍精度浮動小数点数 を用いるようになったため[ 6] macOS Mojave は32ビットアプリケーションを動作させることのできる最後のバージョンとなり、macOS Catalina では起動することができなくなった[ 7]
32ビット版のMicrosoft Windows (Win32) では内部時刻の表現に64ビット化されたFILETIME構造体[ 8] time_tを使っているわけではない。そのため、Windows OS側に関しては、旧OSに関する一部のケースを除き[ 9] [ 10] Microsoft Visual C++ (MSVC) においては、time_tは32ビットのlong intを使って定義されていたため、これらの古い処理系のC/C++ランタイムライブラリ (CRT) を利用して構築されたアプリケーションソフトウェア やDLL などは、2038年問題を抱えていることになる。x64 アーキテクチャの64ビット版Windows OS上ではWOW64 サブシステムによりx86 アーキテクチャ向けに構築された32ビットアプリケーションも動作させることができるが、古い32ビットアプリケーションにおける2038年問題は、たとえWindows OSを64ビット版に入れ替えたとしても回避することはできない。Microsoft Visual C++ 2005以降では、既定でtime_tは__time64_tと等しく[ 11] time_tは64ビット化されるため、古いアプリケーションを新しい処理系およびランタイムで構築し直せば2038年問題を回避できる。
時刻aと時刻bのちょうど中間の時刻を求める時、それぞれのUnixタイムをTaとTbとして、(Ta+Tb)/2 と計算すると、2038年問題の半分以降が経過していればTa+Tbの計算でオーバーフロー し、誤った結果となる。これは[ 12] 時刻の差を計算する : まず、時刻bから時刻aを引いて、その差を求める。差の半分を求める : 求めた差を2で割る。時刻aに加える : 最後に、時刻aに差の半分を加えることで、中間の時刻を求める。 この方法を数式で表すと、次のようになる： 中間時刻=Ta +(Tb −Ta )/2
2001年9月9日問題 は、2001年9月9日にtime_t型の値が9億秒から10億秒と桁が増えることに伴う問題。time_t型の値を文字列（辞書順）でソートしていたことで、「9億 > 10億」と判断され、項目の新旧が正しく判断されず、新しく作られた項目が表示されない、古いものとみなされ削除されるなどの問題が発生した。NTP など、1900年1月1日からの積算秒数で時間を表現するシステムもあり、符号なし32ビットの値が2036年 2月7日 6時28分15秒 (UTC) を超えるとオーバーフローすることによって問題が発生する（→2036年問題 ）。SNTPv4 を定めたRFC 4330 には、最上位ビットが0の場合は時刻が2036年から2104年の間であるとみなして、2036年2月7日6時28分16秒 (UTC) を起点として計算することで2036年問題を回避する方法が書かれている。2038年4月23日問題 - ユリウス通日 を内部日付表現に用いる物のうち、基準日（グレゴリオ暦 1858年11月17日正午）からの修正ユリウス日（MJD）を使用し、かつ16ビットで処理しているシステムでは、日数が16ビットからあふれるために問題が起こる。
^ 「ただし、うるう秒を無視して現在時刻から逆算した値を使用する」として運用されていることが専らである。
^ Cではオーバーフロー発生時の動作は未定義。整数が2の補数 でオーバーフローした値が負 と扱われる場合、2038年1月19日3時14分7秒の次は1901年12月13日20時45分52秒 となる。
^ 計算機による計算においては、このような一見して何の変哲もない式によるバグは入力数値がある程度大きくならないと露呈しにくく、この問題に限らず普遍的なものであり、一般に注意を要する。
^ 2 × 24 × 365.2425) ≒ × 1011 太陽系 の寿命よりもはるかに長い（太陽 の白色矮星 化は西暦68億年ごろ）。
