2038 年問題とは何ですか?その影響を防ぐにはどうすればよいですか?

2038 年バグ: 問題の理解と軽減

2038 年バグは、以下に依存するシステムにおける時間表現の制限に起因します。 32 ビットの符号付き整数で、特定のエポック日 (通常は 1 月) からの秒数を記録します。 1、1970 年）。

1. 2038 年問題とは何ですか?

内部表現が 2038 年 1 月 19 日の 03:14:07 UTC に最大値に達すると、カウントは時間を表す負の数に戻ります。この不一致は 32 ビットの制限から生じます。整数。

2.発生理由と発生方法

この問題は、内部表現に 32 ビットの制限を超えてタイムスタンプを保存する容量がないために発生します。その結果、最大値を超える時刻はそれより前の日付として誤って解釈されます。

3. 2038 年バグの解決

この問題を軽減するには、次のことが重要です。

• 64 ビット長のデータ型を使用します。 データ型を使用するGNU C の Long Long や Java の Long integer など、より大きな表現能力を使用すると、タイムスタンプが解決されます。オーバーフローの問題。
• 代替の MySQL 列タイプを検討してください: データベース内の日付ストレージの場合、純粋な日付情報には DATE を使用します。精度を高めるには、DATETIME ではタイム ゾーンが考慮されないことを認識して、TIMESTAMP の代わりに DATETIME を使用します。
• MySQL 8.0.28 以降にアップグレードします: MySQL はバージョン 8.0 でこのバグに対処しました。 28、改善されたタイムスタンプを提供します取扱い

4． TIMESTAMP の代替案

将来の同様の問題を回避するために、64 ビット整数などの拡張容量を持つデータ型の利用を検討してください。

5.既存のアプリケーションの破損の防止

TIMESTAMP に依存する既存のアプリケーションの場合は、オーバーフローを処理する戦略の採用を検討してください。これらの戦略には次のものが含まれます。

• TIMESTAMP を DATETIME に変換する: データベース テーブルの列を変更して、TIMESTAMP から DATETIME に切り替えます。これにより、より広い時間範囲がサポートされます。
• 誕生日と将来の日付には DATE を使用します: を超える日付のオーバーフローを防ぐには、 32 ビット制限。DATE 列型を使用して純粋な日付として保存します。

以上が2038 年問題とは何ですか?その影響を防ぐにはどうすればよいですか?の詳細内容です。詳細については、PHP 中国語 Web サイトの他の関連記事を参照してください。