2038年問題

UNIXの日時管理は、1970年1月1日00:00:00を基準(これをThe Epochという)とし、その時間からの経過秒数で扱っている。なお、この経過秒数に閏秒は含まれない。

この経過秒数は32ビットで表現されるが、符号を考慮すると有効桁は31ビットしかない。そのため「1970年1月1日 00:00:00 + 0x7fffffff秒より後が表現できない」という問題を抱える事となった。

即ち、2038(令和20)年1月19日12:14:07(日本時間)(@176)までしか表現できないことを意味している。

CやC++は、time_t型を順次64ビット(有効桁63ビット)などに延長するように改良されている。

このため、比較的新しいC/C++処理系では、2038年問題の回避が出来るようになった。但し、古い設計の処理系などには、問題が残されていることになる。

例えば、gzipのように、ファイルフォーマットの要素として32ビットのtime_tを含む場合、同様に2038年問題を生じる。ファイルフォーマットの変更が必要となるが、互換性などから難しい問題となる。このためRFC 1952では0を格納することになっており、実際の実装でもgzip-1.9からはオーバーフロー時には0を格納するようになっている。