2038 年問題(Y2K38)を解説

2038 年問題とは?

Unix タイムスタンプは伝統的に、1970 年 1 月 1 日 00:00:00 UTC からの秒数を数える 32 ビット符号付き整数として保存されます。32 ビット符号付き整数の最大値は 2,147,483,647 で、これは 2038 年 1 月 19 日 03:14:07 UTC に相当します。その 1 秒後、整数は -2,147,483,648 にオーバーフローします。Unix タイムスタンプとして解釈すると、この負の値は 1901 年 12 月 13 日に相当し、影響を受けるシステムを約 137 年前へ送り戻します。

オーバーフローの値

• 2^31 − 1 = 2,147,483,647(32 ビット符号付き整数の最大値)
• 2,147,483,647 を日付に = 2038 年 1 月 19 日 03:14:07 UTC
• 2,147,483,647 + 1 は −2,147,483,648 にオーバーフロー(32 ビットで最も小さい値)
• −2,147,483,648 を日付に = 1901 年 12 月 13 日 20:45:52 UTC

どのシステムが危険か?

この問題は、タイムスタンプを 32 ビット符号付き整数で保存するシステムに影響します:

• 32 ビットの time_t を使う組み込みシステムやマイコン
• 32 ビット向けにコンパイルされ、タイムスタンプに time_t や int を使うレガシーな C/C++ コード
• まだ稼働中の 32 ビットハードウェア上の古い Linux カーネル(5.6 より前)
• MySQL の TIMESTAMP 列 — 2038-01-19 までに制限。代わりに DATETIME を使う
• タイムスタンプを 32 ビット値で符号化する一部のネットワークプロトコルやファイル形式
• 数十年の寿命を持つ産業用制御システムや IoT 機器のファームウェア

どのシステムが安全か?

現代のコードとインフラのほとんどはすでに影響を受けません:

• あらゆる 64 ビット OS — Linux(glibc 2.34+ は 32 ビットハードウェアも修正)、macOS、Windows
• Python — タイムスタンプは 64 ビット浮動小数点を使い、西暦 2 億 9200 万年をはるかに超えて安全
• JavaScript — Date は 64 ビット IEEE 754 浮動小数点を使い、西暦 275,760 年まで安全
• Go と Rust — 内部で int64 を使い、数十億年安全
• Java — java.time.Instant は long(64 ビット)を使い、西暦約 2 億 9200 万年まで安全
• PostgreSQL TIMESTAMP — 2038 年以降の日付も正しく保存
• MySQL DATETIME — 範囲は 1000-01-01〜9999-12-31 で影響なし

2038 年問題 FAQ

2038 年問題とは?

2038 年問題(Y2K38)は、Unix タイムスタンプの保存に 32 ビット符号付き整数を使うシステムが、2038 年 1 月 19 日 03:14:07 UTC にオーバーフローするバグです。32 ビット符号付き整数の最大値は 2,147,483,647 です。その 1 秒後、整数は -2,147,483,648 に折り返し、これは 1901 年 12 月 13 日に相当します。

2038 年 1 月 19 日の Unix タイムスタンプは?

2038 年 1 月 19 日 03:14:07 UTC の Unix タイムスタンプは 2,147,483,647 で、32 ビット符号付き整数の最大値(2^31 - 1)です。32 ビットシステムで 2038 年オーバーフローが起こる正確な瞬間です。

Y2K38 は Y2K と同じ?

いいえ。Y2K(2000 年問題)は年を 2 桁で保存するプログラムが原因でした。Y2K38 は Unix タイムスタンプを 32 ビット符号付き整数で保存し、2038 年にオーバーフローすることが原因です。原因も影響を受けるシステムも異なります。

2038 年にインターネットは壊れる?

大きくは壊れないでしょう。インターネットインフラの大半はすでに 64 ビットシステムへ移行済みです。リスクは組み込みシステム、古い IoT 機器、数十年更新されていないソフトウェアに集中します。現代の OS・言語・データベースはすでに安全です。