2038年問題
対策としては、time_t型を符号付き64ビット整数型(一般にはlong long int型)にするという方法がある。符号付き64ビット整数型の場合、上限は9,223,372,036,854,775,807(2 − 1)である。これを年数に変換するとおよそ西暦3000億年まで使用できるので、事実上問題が発生することはない。64ビット版のオペレーティングシステムや処理系では、time_t型は符号付き64ビット整数型で表されるようになってきている。UNIXベースのOSでは、64ビット版で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ビット化が困難な環境に限って適用すべき方法とされる。
macOS (Mac OS X 10.0) ではNSDateクラスにて協定世界時の2001年1月1日0時ちょうどをエポックタイムとして刷新し、また経過時間の内部表現として倍精度浮動小数点数を用いるようになったため、これらを使用している限り、2038年については問題を回避できる。
2038年問題(にせんさんじゅうはちねんもんだい)は、2038年1月19日3時14分7秒(UTC、以下同様)を過ぎると、コンピュータが誤動作する可能性があるとされる年問題。