聊一聊2038年问题

庚子年是中国传统的 60 甲子纪年法。擅长观测的古人很早就发现，每当年份执行到庚子这一年，自然灾害变多，突发事件频频，一些震动世界、影响安定的大事件也容易发生在这一年。而我们现在所处的 2020 年就是新一轮的庚子年，现在都 4 月了，很多网友都调侃说新的一年什么事情都没做，光在见证历史了。

当然了，作为一个技术博主，我并不是来给大家科普庚子年的，今天我们要说的是计算机中的一个比较危险的年份——2038 年。

PS：本期内容我制作了配套视频，点击即可查看：https://www.bilibili.com/video/BV1Qf4y1U7sR/

2038 年问题

在说 2038 年问题前，我们需要先明白计算机是如何存储系统时间的。

在 Unix 或类 Unix 系统中，都是以 1970 年 1 月 1 日 0 点 0 分 0 秒作为时间的基准点，用秒数来表示系统时间，也即当前系统时间是从基准时间（1970 年 1 月 1 日 0 点 0 分 0 秒）走过多少秒之后的时间。

用公式简单表示就是这样：系统时间 = 基准时间 + 秒数

因为基准时间是确定的，所以我们唯一需要考虑的就是秒数应该如何保存。在当时那个年代，计算机硬件资源非常紧缺，用 16 位表示数据就已经是一个非常奢侈的选择了。因此当时的设计者都认为用 32 位存储秒数已经“足够大”了。所以从那个时候开始使用 32 位来表示秒数。

我们知道在二进制中，32 位数能表示的最大的数是，不过为了能够让时间可以往前往后数，会用第一位作为正负的判断位，第一位如果为 0，则说明为正；若第一位是 1，则说明为负。因此，在 Unix 或类 Unix 系统中，这个数被分成了 2 部分，分别是和。这样我们就可以以 1970 年 1 月 1 日 0 点 0 分 0 秒作为时间的基准点，往前往后每过一秒就加一个数字，依此来计算时间。

image

这个时间的最后结束点是 2038 年 1 月 19 日 03:14:07，一旦越过这个瞬间，时间将会“绕回”（wrap around）且在内部被表示为一个负数，并造成程序无法工作，因为它们无法将此时间识别为 2038 年，而可能会依个别实现而跳回 1970 年或 1901 年。因此可能产生错误的计算及动作。就像下面这样。

img

所以如果时间将近 2038 年时，还存在 32 位机器在世界中运行，那将会受到 2038 年问题的影响。

从这也可以看出为什么很多厂商都不再提供 32 位支持了。

危害性

可能很多人都疑惑，这不就是个时间问题吗？有你说的那么严重吗？

当然，简单来看这就是个时间问题，而且换成 64 位的机器 2038 年问题就会自动消失了。但这只是一厢情愿，对于嵌入式设备来说，现在还有大量 32 位系统在全球各地运行，谁也无法保证这些系统在 2038 年之前就能光荣退役。

而且很多程序都会依托时间进行计算，最简单的就是银行的贷款利息等金融服务的计算，如果不解决，就一定会出现各种混乱。

而且，由于这个特殊时间点的存在，并不是说只有到 2038 年的时候才会出现问题，比如前两年就出现过，将 iPhone/iPad 等设备日期设置成 1970 年 1 月 1 日，设备就会变砖，并且无法通过寻常的备份还原等手段进行恢复。就是因为，iOS 是基于 Unix 操作系统构建的。

image

而且事实上 2038 年问题的范围远不止于此。前面谈到的问题都还是操作系统运行时表示数据的溢出，但还有一些数据是静静在躺在某个磁盘上，当时间走到 2038 之后再把它它们翻读出来，一样会出现问题。

我们知道文件都有几种时间属性，比如创建时间，最后一次访问时间，最后一次修改时间。如果该时间类型也是 32 位有符号数，那在 2038 之后的某个早晨，试想一下你和朋友喝着咖啡，回忆起 2038 年以前的某次旅游，你兴高采烈说着之前见闻，并拿出手提电脑打开之前拍下的照片，这时扫兴的事情将会发生，文件打不出或者出错。

所以说，如果这个问题不解决，夸张点说，未来真的可能会出现，全世界大部分的电子设备全部瘫痪的场景。

如何解决

2038 年问题的根源就是使用了 32 位有符号整数来表示时间，看起来它的解决方案非常的简单，直接粗暴地将32 位有符号整数 修改成 64 位有符号整数。

如果真的这样做，那对这个世界会产生什么影响呢？在修复 2038 年问题那一天，估计全世界人已都在做同一件事情：

所有应用程序统统重新编写代码，至少得重新编译才能在新系统上运行
所有受影 2038 年影响的文件系统对应的分区，得统统格式化掉
在那天有的互联网服务都统统下线了，整个应用网络处于瘫痪状态
更离奇的是，你在银行的存款被清零了；对于那个贷款的家伙来说是个好事情，因为他们不用向银行还钱了

因此这样的做法无异于格式化整个世界，创建一个新的世界。我们当然不能这样。

不过，遗憾的是，当前并没有针对现有的 CPU／操作系统搭配的简单解决方案。直接将时间更改为 64 位模式将会破坏对于软件、数据存储以及所有与二进制表示时间相关的部分的二进位兼容性。更改成无符号的 32 位整数则会影响许多与两时间之差相关的程序。

那我们就真的无能为力了吗？并不是，我们还可以：

推广 64 位机器/软件的使用，争取当那一天来临的时候波及的设备尽可能少
做好对 32 位软件的兼容

不过大家也没必要恐慌，毕竟离 2038 年还有 18 年的时间，Linux 社区也开始着手处理这个问题了，离目标不远了，胜利在望。

最后

如果你真的有兴趣的话，可以到time.is/Unix这个网站，他会告诉你从 1970 年 1 月 1 日 0 点 0 分 0 秒开始到现在一共过了多少秒。

以上就是这次介绍的 2038 问题了，相信很多工程师都知道这个问题，也许到时候世界上就没有 32 位的机器了，或者是说已经有大佬解决了这个问题。毕竟已经有过千年虫问题的前车之鉴了，很多人已经知道要提前做准备了。

最后，如果你觉得我的文章对你有帮助的话，不妨给个关注支持一波，

image