到2038年1月19日那天，Unix时钟会失效吗？

Posted 2021-04-30 云头条

如果你密切关注Linux领域的发展和动向，肯定了解2038年错误（Year2038 bug）。这个问题之所以会存在，是由于到了2038年1月19日那天，可以用Unix带符号的32位整数时间格式表示的最新时间是03:14:07 UTC。之后，使用标准时间库的C程序会开始遇到日期问题。

2000年问题又叫千年虫或Y2K问题，这是与日历日期的格式和存储有关的计算机错误。这个问题之所以会出现，是由于早期计算机中的存储空间很昂贵。于是，为了减少存储空间，程序员使用了六位数的MMDDYY日期格式。由于程序能够为年份YY添加19，它节省了资金，但缩减了文件和数据库的大小。然而，这种程序发现很难区别2000年、1900年和19100年。

为了解决这个问题，多国政府专门成立了委员会，确保关键基础设施解决了这个问题。现在，类似的2038年问题成了全球计算机世界的另一个问题。

2038年问题又叫Unix千年臭虫或Y2K38错误。在时间值以带符号的32位整数来存储或计算的数据存储情况下，这个错误就有可能引发问题。

可以用Unix带符号的32位整数时间格式来表示的最新时间是2038年1月19日03:14:07UTC，这是1970年1月1日之后过了2147483647秒。过了那个时间后，由于整数溢出，时间值将作为负数来存储，系统会将日期读为1901年12月13日，而不是2038年1月19日。

用简单的语言来说，Unix机器最终将会耗尽存储空间来列举秒数。所以，到那一天，使用标准时间库的C程序会开始出现日期问题。你可以在维基百科上详细阅读更多的相关内容（https://en.wikipedia.org/wiki/Year_2038_problem）。

下面这个动画显示了2038年错误将如何重置日期：

资料来源：维基百科

目前，2038年错误没有什么通行的解决方案。如果对用于存储时间值的time_t数据类型的定义进行更改，依赖带符号的32位time_t整数性质的应用程序就会出现一些代码兼容性问题。假设time_t的类型被更改为不带符号的32位整数，那将加大最新的时间限制。但是，这会对由负整数表示的1970年之前的日期造成混乱。

使用64位架构的操作系统和程序使用64位time_t整数。使用带符号的64位值可以将日期延长至今后的2920亿年。

已有人提出了许多建议，包括以带符号的64位整数来存储自某个时间点（1970年1月1日或2000年1月1日）以来的毫秒/微秒，以获得至少30万年的时间范围。其他建议包括用新的库重新编译程序，等等。这方面的工作正在开展之中；据专家们声称，2038年问题解决起来应该不难。

你觉得Linux中的2038年问题值得关注吗？欢迎留言交流！