2038 年問題の原因、結果、解決策は何ですか?

2038 年問題: 問題と利用可能な解決策について

2038 年問題は、符号付き 32 ビット整数が広く使用されたことに起因しています。はシステム時間を表し、原点は 1970 年 1 月 1 日に設定されます。エポックが 32 ビット整数の最大値を超えると、これらのシステムは重大な課題に直面することになります。

発生と影響

2038 年 1 月 19 日火曜日、午前 3 時: 14:07 UTC、時間を表す 32 ビット整数がオーバーフローし、システムがそれを負の値として解釈します。 番号。これにより、日付と時刻が 1901 年 12 月 13 日に対応する値として保存されます。

緩和戦略

この問題に対処するには、次のようないくつかのアプローチが利用可能です。

• 64 ビット データ型を使用する:日付と時刻を保存するために長いデータ型を実装すると、将来の拡張のための十分なスペースが確保されます。
• MySQL/MariaDB の代替: 時間が重視されないアプリケーションの場合は、DATE カラム型を使用します。精度を高めるには、TIMESTAMP の代わりに DATETIME を使用します。
• MySQL のアップグレード: 2038 年以降の日付を処理するための変更が含まれているため、MySQL 8.0.28 以降にアップグレードします。

2038 年傾向の代替案型

データベース ストレージには、可能な限り大きなデータ型を採用することを検討してください。例は次のとおりです。

• GNU C および POSIX/SUS では、long long 型を使用します。
• PHP では、sprintf('%u'...) または BCmath 拡張機能を使用します。 .

レガシーアプリケーション

TIMESTAMP を利用するレガシー アプリケーションを変更するには、慎重な検討が必要です。より広範囲の日付を処理できるため、代わりに DATETIME の使用を検討してください。

既存の TIMESTAMP フィールドを DATETIME に変換するには、次の手順に従います。

1. 既存の TIMESTAMP フィールドを保存する一時列を作成します。 TIMESTAMP データ。
2. 元の TIMESTAMP と同じ名前の新しい DATETIME 列を追加します。
3. 一時列のデータを使用して新しい DATETIME 列を更新します。
4. 一時列を削除します。

詳細情報のリソース

• 2038 年問題 (Wikipedia): https://en.wikipedia.org/wiki/ Year_2038_problem
• インターネットは 30 年後に終わる: https://spectrum.ieee.org/tech-talk/telecom/internet/the-internet-will -30年後の終わり

以上が2038 年問題の原因、結果、解決策は何ですか?の詳細内容です。詳細については、PHP 中国語 Web サイトの他の関連記事を参照してください。