一个答案提到了
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 年之后的时间戳。现在主要关注的是文件系统； inode 大于 128 位的 ext4 文件系统（运行
dumpe2fs并查找“Inode 大小”）就可以，内核为 5.10 及更高版本的 XFS 文件系统也可以，使用该bigtime选项（这在 RHEL 8.3 及更高版本上受支持，我不确定 RHEL 7 文件系统限制为 2038 个；在安装时产生警告）。当前的解决方案是尽可能使用 64 位时间戳。
XFS 目前支持日期到 2486。 Linux 上的 64 位时间戳可以表示大约 292,000,000,000 年之前的日期。