現代の21世紀のLinuxでのY2K時間オーバーフローの問題はいつ発生しますか?

現代の21世紀のLinuxでのY2K時間オーバーフローの問題はいつ発生しますか?

引用するなぜUnixの時間は1970-01-01から始まりますか?

言及された答えの1つ

Unix時間は2038年1月19日03:14:07 GMTで終了します。 2038年1月19日03:14:08 GMTで32ビットUnix時間を使用しているすべてのコンピュータでオーバーフローが発生します。いわゆる「2038年問題」だ。一部の人々は、これが「2000年問題」よりも大きな問題になると信じています。 2038年の問題に対する解決策は、Unix時間を64ビット整数として保存することです。ほとんどの64ビットオペレーティングシステムはすでにこの作業を開始していますが、多くのシステムは2038年以前に更新されない可能性があります。

  • RHEL / CentOS 7.9を無期限に実行することにした場合、誰かが64ビット時間整数(署名されているか署名されていない)で実行されているのか、時間の問題がいつ発生するのかについてコメントできますか?
  • 最新のLinux(RHEL / CentOS 9など)のタイムオーバーフローの問題に対する現在のソリューションは何ですか?したそれらこの問題は、RHEL 5のようにしばらく前に解決されていますか、それでもまだ目立たない問題ですか?
  • 現在の解決策が何であれ、数学的には長すぎるしかありません。そうですか?それでは、現在起こっている最善の解決策において、時間オーバーフローはいつ最終的に発生し、今後発生日はいつですか?

答え1

  1. 64ビットプログラムはすでに2038年以降のタイムスタンプを処理できます。今主な関心事はファイルシステムです。このオプションを使用するdumpe2fsと、カーネル5.10以降のXFSファイルシステムと同様に動作します。bigtimeRHEL 8.3以降のバージョンでサポートされています。 RHEL 7ファイルシステムの制限である2038についてはわかりません。インストール中の警告の生成)。

  2. 現在の回避策は、可能な限り64ビットタイムスタンプを使用することです。

  3. XFSは現在最大2486の日付をサポートしています。 Linuxの64ビットタイムスタンプは、約292,000,000,000年前の日付を表すことができます。

関連情報