一部のコードが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倍以上です。
追加読書ここ。
答え2
私の質問はなぜこれが起こるのですか？
32 ビット符号付き整数の最大値は 2147483647 なので、68 年と秒が少し超えています。したがって、1970年から秒を計算する符号付き32ビット整数範囲は2038年に終了します。
2000年の問題と似ていますか？
ある意味で。 Y2Kは、小数点以下の2桁のスペースのみを維持し、32ビットのみを維持することです。
別のオペレーティングシステムを使用して問題を解決できますか？
確かに。たとえば、NTFSの場合、Windowsは64ビット値を使用し、1601から始めて100nsティックを計算します。これは30828まで十分です。
それとも、32ビットプロセッサは実際には2038年以降の時間を処理できませんか？
いいえ、32ビットだけでは十分ではありません。 32ビットプロセッサで実行されるプログラムは、複数の32ビットワードといくつかのロジックを使用してより大きな数字を処理できます。これが暗号化に必要な大きな数字を処理する方法です。 （また、この32ビット時間形式が32ビットまたは16ビットシステム（またはより奇妙なシステム）で最初に使用されたかどうか疑問に思います。）
現時点では、32ビットシステムの多く/ほとんどの既存のソフトウェアが32ビットタイムスタンプを使用し、OSインターフェイスがこれを提供するため、これは「ただ」互換性の問題です。 64ビットタイムスタンプを使用する新しいシステムを構築するのは簡単ですが、以前のソフトウェアと互換性のある方法で構築するのははるかに困難です。 （しかし、私が知っている限り、32ビットLinuxでの64ビット時間のサポートはすでに追加されているか開発中です。）