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

2038 年バグ: 原因、影響、および解決策

2038 年問題を理解する

2038 年問題は、特定のコンピューターの動作に起因します。システムは、符号付き 32 ビット整数を使用してタイムスタンプを保存します。この形式では、表現可能な最大時刻が 2038 年 1 月 19 日の 03:14:07 UTC に制限されます。この時点を超えると、整数が「ラップ アラウンド」し、時刻の計算が不正確になります。

その理由と方法発生します

この問題は、コンピュータの時計が UNIX の起動以来秒数をカウントするために発生します。エポック (1970 年 1 月 1 日)。このカウントが 32 ビット符号付き整数の最大値を超えると、負の値にリセットされます。この変更により、時刻は 2038 年ではなく 1901 年 12 月の時点として解釈されます。

問題の解決策

• 64 ビット データ型を使用します。 タイムスタンプの 32 ビット データ型を 64 ビット データ型に置き換えるラップアラウンドの問題を解決します。
• MySQL の日付/時刻の代替手段を使用する: MySQL データベースの場合は、時刻情報なしで日付を保存する場合は DATE を使用するか、64 ビットをサポートする DATETIME を使用することを検討してください。
• MySQL のアップグレード: MySQL 8.0.28 以降のバージョンでは完全版が提供されます64 ビット タイムスタンプのサポート。
• サードパーティ ソリューションの探索: さまざまなソフトウェア ライブラリとフレームワークが、2038 年の制限を超えてタイムスタンプを管理するためのソリューションを提供します。

タイムスタンプの代替アプローチストレージ

潜在的な問題を回避するために、開発者は代替タイムスタンプ ストレージ メカニズムを実装できます:

• BCD エンコーディング (バイナリ コード化 10 進数): BCD は数値を格納します4 ビット ニブルのシーケンスとして、最大値が 32 ビット整数をオーバーフローしないようにします。 limit.
• 浮動小数点数: 浮動小数点値はタイムスタンプを表すために広い範囲を提供しますが、精度の制限を考慮する必要があります。

TIMESTAMP を使用した既存のアプリケーションへの対処

に大きく依存するアプリケーションの場合TIMESTAMP については、次の戦略を検討してください:

• 64 ビット システムへの移行: 64 ビット データ型をサポートするハードウェアとオペレーティング システムにアップグレードします。
• TIMESTAMP から DATETIME への変更: 既存の TIMESTAMP 列を DATETIME に変換します
• カスタム タイムキーピング メカニズム: 大きなタイムスタンプ値を効果的に処理するアプリケーション固有のタイムキーピング メカニズムを開発します。

結論

2038 年バグは、32 ビットのタイムスタンプ形式に依存するコンピューター システムに潜在的な課題をもたらします。ソフトウェア エンジニアは、問題を理解し、適切なソリューションを採用し、代替ストレージ メカニズムを検討することで、期限が到来してもアプリケーションが影響を受けないようにすることができます。

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