聊一聊2038年问题

article/2025/9/22 8:39:59

庚子年是中国传统的 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 位数能表示的最大的数是 $2^{32}-1$ ，不过为了能够让时间可以往前往后数，会用第一位作为正负的判断位，第一位如果为 0，则说明为正；若第一位是 1，则说明为负。因此，在 Unix 或类 Unix 系统中，这 $2^{32}-1$ 个数被分成了 2 部分，分别是 $+2^{31}-1$ 和 $-2^{31}$ 。这样我们就可以以 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 年以前的某次旅游，你兴高采烈说着之前见闻，并拿出手提电脑打开之前拍下的照片，这时扫兴的事情将会发生，文件打不出或者出错。

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