2038年的末日问题

本文最后修改于 530 天前,部分内容可能已经过时!

视频点此

霍金说2032年是世界末日——当然怹老人家到底说没说过咱也不知道。到底是不是真的咱也不敢问。只是那一年有个小行星会跑到地球附近,碰撞概率是千分之一。概率虽高,但仍有很大的不确定性因素。所以当下的人们,更重视并着手解决着另一个世界末日——Unix世界的末日。因为它已经不可避免的会发生,并且发生时间已经明确了:格林尼治2038年1月19日3点14分7秒,北京时间11点14分7秒。这一点可以跟Siri证实一下。

为什么?


就像世纪初的千年虫,2038年是属于Unix的“千年虫”——使用 POSIX 时间的 32 位计算机应用程序在到达2038年1月19日3点14分7秒后,将会跳到1901年12月13日20点45分52秒继续。怎么会这样?

在Unix世界中,时间是通过一个秒数——从Unix创世元年(1970.1.1 0:0:0)到现在经过的秒数——记录的。所以在Unix里边看到的时间,都是通过创世纪时间+秒数得到的。而这个秒数,被保存在了一个32位有符号整形中,通过正负号表示0时刻之前和之后。

如果你学过编程,你应该就知道32位有符号整形是什么意思:32位的二进制数,其中最高位表示正负。位数有限,则可以表示的数字便也会有极值。这个最大值取在01111111 11111111 11111111 11111111这个二进制数上,对应的十进制就是2^31-1=2147483647。这么多秒换算成时间,就是68年零18天3小时14分7秒。加上创世纪的1970年1月1日0时刻,便得到了这种记录方式的最大时间——2038年1月19日3点14分7秒。再往后,二进制的数字进位,首位变成了1。而首位为1意味着是负数而不是+1,所以时间跳回,Y2038问题便出现了。


这个问题有什么影响吗?至少使用time_t函数的C语言程序会导致时间溢出,Unix系统也不例外。但几乎可以肯定的是,不会有千年虫的影响大。因为OpenBSD直接粗暴的把变量换到64位有符号整形来保存,Linux内核虽然不能这么干,但一直在致力于解决这个问题。而截止到5.1内核版本,其已经开始引入2038年安全的系统调用了。最终目的是让老程序能转换到正确时间,新程序则直接用64位保存时间,这便可以让时间正确运行到大约2920亿年以后。也就是说,64位的“千年虫”将在2920亿年以后出现。而你的电脑硬盘则在38年后的几十年便转秃噜轴了,太阳也早在两千八百多亿年前就变成了红巨星并一点点的冷却了,所以64位的“千年虫”,我们怕是见不到了。

创建时间:2019年09月21日
最后修订:2019年09月21日
另请参阅:
DeepinDebian操作系统linuxredhatubuntuCentOSArchlinuxManjaro
上一篇
打赏
下一篇

添加新评论