引用するなぜ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
64ビットプログラムはすでに2038年以降のタイムスタンプを処理できます。今主な関心事はファイルシステムです。このオプションを使用する
dumpe2fsと、カーネル5.10以降のXFSファイルシステムと同様に動作します。bigtimeRHEL 8.3以降のバージョンでサポートされています。 RHEL 7ファイルシステムの制限である2038についてはわかりません。インストール中の警告の生成）。現在の回避策は、可能な限り64ビットタイムスタンプを使用することです。
XFSは現在最大2486の日付をサポートしています。 Linuxの64ビットタイムスタンプは、約292,000,000,000年前の日付を表すことができます。