Back

コンピュータは2038年に停止するのか?(2038年問題)

1999年の終わりに、世界は「2000年問題(Y2K)」を恐れていました。年を2桁(99)として保存していたコンピュータが、2000年を1900年と解釈し、混乱を引き起こすと予想されていました。

今、同様の、おそらくもっと深刻な問題が近づいています。

それは 2038年問題 です。

1. Unix時間

コンピュータはどのように時間を保存するのでしょうか?ほとんどのシステムは Unix時間 を使用しています。

これは、1970年1月1日 00:00:00 (UTC) から経過した 秒数 をカウントします。

例えば、これを書いている時点で、1970年から約 17億 秒が経過しています。

2. 32ビットの制限

問題は、多くの古いシステムやソフトウェアがこの値を保存するために 符号付き32ビット整数 を使用していることです。

32ビット整数が保持できる最大値は 2,147,483,647 です。

Unix時間に変換すると、これは正確に 2038年1月19日 03:14:07 (UTC) に相当します。

3. その日が来たら

この時間の1秒後に何が起こるのでしょうか?

数値は最大値を超えてオーバーフローし、最小値である -2,147,483,648 にラップアラウンドします。

システムはこの時間を 1901年12月13日 として解釈します。

これにより、以下のことが発生する可能性があります。

  • データベースの日付計算が失敗する。
  • スケジューリングシステムが過去の予約を入れる。
  • 組み込みデバイスやレガシーサーバーがクラッシュする。

4. 解決策

解決策は単純ですがコストがかかります。時間変数を 64ビット に拡張することです。

64ビット整数の最大値は約 900京 です。これは宇宙の年齢(約2900億年)よりもはるかに長い期間を表すことができ、事実上永遠に安全です。

現代の64ビットオペレーティングシステムや言語は、すでに64ビット時間を使用しています。懸念されるのは、まだ稼働している32ビット組み込みデバイスやレガシーコードです。

結論

2038年は遠い未来のように思えますが、長期契約や年金を扱うシステムではすでに問題が発生している可能性があります。

開発者として、コード内の日付変数が32ビットか64ビットかを確認する価値はあります。それは将来の災害を防ぐための第一歩です。

TechUnixTimeBug

関連ツールを見る

Pockitの無料開発者ツールを試してみましょう