一部のコードが2038年以降に実行されない理由については、Stack Overflowで多くの質問をしましたが、回答は通常64ビットOSにアップグレードすることをお勧めします。私の質問はなぜこれが起こるのですか？ 2000年の問題と似ていますか？別のオペレーティングシステムを使用してこの問題を解決できますか？それとも、32ビットプロセッサは2038年以降の物理的に時間を処理できませんか？なぜ？ （私はLinuxを初めて使用するので簡単な質問かもしれませんが、実際に答えがわかりません。）
ベストアンサー1
Unixシステムの時間は、エポック（1970年1月1日00:00 UTC）以降の秒数で追跡されます。 2038年には、この時間が32ビット整数の記憶容量を超えています。これが64ビットカーネルが問題を解決する理由です。引用するウィキペディア:
多くのプラットフォームでは、特定の時点を表すUnix time_tデータ型は、前のセクションで説明したように、Unix時間数を直接エンコードする伝統的に32ビット（以下を参照）の符号付き整数です。 32ビットは、全範囲が約136年という意味です。表現可能な最も短い日付は1901年12月13日金曜日であり、表現可能な最も長い日付は2038年1月19日火曜日です。 UTC 2038-01-19 03:14:07 この表現は1秒でオーバーフローします。このマイルストーンへの期待は興味深く、恐ろしいです。 2038年の質問を参照してください。
一部の最新のオペレーティングシステムでは、time_tが64ビットに拡張されました。これは、表現可能な時間を双方向に約2,930億年延長し、これは各方向で現在の宇宙年齢の20倍以上です。
追加読書ここ。