2038年問題：Unixタイムスタンプの限界
時間が止まるのではありません。特定の保存形式が、表せる最大の正の数に達します。
限られた箱に入る、秒のカウンター
Unix時刻は1970年1月1日0時0分0秒UTCからの秒数で、うるう秒を数えません。符号付き32ビット整数の最大値は2,147,483,647です。Unix秒として読むと、2038年1月19日3時14分7秒UTCになります。一秒後の値は、その形式には収まりません。日付自体は普通の日で、問題は保存できる数の上限にあります。
すべてのコンピューターが、同じではない
影響するのは、この制限された形式を使い続けるシステム、ファイル形式、通信規約、データベースなどです。より広い型なら後の日付も表せます。ただし新しいアプリでも古い部品と情報交換する場合があり、画面の時計を見るだけでは確認できません。範囲外の値を拒否するか、切り詰めるか、誤解釈するかは実装次第です。すべての機器が1901年に戻る、インターネットが止まる、という説明は正確ではありません。
もう一つの落とし穴は、千倍の違い
秒とミリ秒は別の単位です。2,147,483,647をミリ秒として入力すると、2038年ではなく1970年1月になります。桁数から単位を推測する方法は、特に古い日付や小さな値では信頼できません。当サイトのツールでは単位を明示的に選びます。不具合を調べるときは、値と単位、期待するUTCの結果を一緒に記録しましょう。小さな習慣で、多くの日付の間違いを防げます。
境界を、ツールで確かめる
秒を選び、2147483647と2147483648を変換してみてください。どちらも2038年で、一秒違いの結果になります。このブラウザーツールは符号付き32ビットのUnix秒には制限されていないためです。ただし、これはこの計算の確認であり、所有するすべてのシステムの検証ではありません。アプリを調べるには、境界の前後の日付で保存・読み出し・外部連携を試します。正しく表示できることは、確認事項の一部です。
直感を試してみよう
出典・参考資料
独自の解説と計算例を掲載しています。参考リンクは、基になる規格や文書を示しています。