2000年、Y2Kバグは多くの問題なく訪れ、過ぎ去りました。 広範な障害の予測にもかかわらず、長期的および直前の計画と介入の両方によって危機は回避され、 重要なシステムに障害は発生しませんでした。 それ以来、影響を受けた少数のオペレーティング システムやアプリケーションは、ほとんどの場合、アップグレードされるか、置き換えられるか、引退しました。
すべての 32 ビット Unix/Linux ベースのシステムは、エポック、つまり 1970 年 1 月 1 日の 00:00:00 からの秒数として、システムクロック時刻を内部に保存します。 この内部データ型であるtime_tは、ほとんどの場合、32ビット（4バイト）の符号付き整数である。 (ほとんどの Unix や Linux システムがそうであるように) 対象のシステムが POSIX 標準に従っている場合、この 32 ビット符号付き整数で seconds-since-the-Epoch として表現できる最新の日時は、2038 年 1 月 19 日火曜日 3:14:07 UTC です。
この日時の後、システム時間の内部表現は、32 ビット符号付き整数で格納できる最大の数、2147483647 まで到達することになります。 その1秒後には負の数である-2147483648にラップアラウンドする。 現在のアプリケーションは、この負の数を古い年（1901年）として解釈するか、システムクロックを2038年1月19日03時14分07秒にフリーズさせます。 これは、アプリケーションやオペレーティング・システムが、ハングしたシステム時計や1901年を示す時計で動作するように設計されていないため、おそらく失敗します。
32ビット・プロセッサを使用するシステム、または64ビット・プロセッサ上で32ビットモードで動作するオペレーティング・システムやアプリケーションに対して、（既存のアプリケーションを破壊しないような）有効な修正プログラムは存在しません。 現在の多くの Unix/Linux オペレーティング システムは、64 ビット プロセッサ上ですでに 64 ビット モード (対応する “long” time_t) で動作しており、ほとんどの場合、これで問題が解決します。
長い 64 ビット time_t をサポートするオペレーティング システムは、内部システム クロックに関して 2038年問題の影響を受けないことがほとんどです。 しかし、32 ビットの time_t を使用するアプリケーションは、アプリケーションを実行しているシステムが完全な 64 ビット動作をサポートしていても、失敗することがあります。
以下は、主流の Unix/Linux リリースにおける Unix 2038 サポートの現在の状態の概要です。
私は、今後 5 年から 10 年の間に、すべての主要なデスクトップ オペレーティング システムが完全に 64 ビットになっていると予想しています。 さらに、トリクルダウン効果により、適用可能でコスト効果のあるところでは、現在のシステムを 64 ビット構成に置き換えることができるでしょう。 Bill Bradford は SunHELP の作成者兼管理者で、妻の Amy と共にテキサス州ヒューストンに住んでいます。