“2038年问题”的软件缺陷

原创于 2025-09-05 08:33:43 发布 · 1k 阅读

CC 4.0 BY-SA版权

文章标签：

124 篇文章

订阅专栏

64 篇文章

订阅专栏

这是一个非常经典且有趣的问题！简单直接的回答是：

因为一个被称为“2038年问题”的软件缺陷，其根源在于早期计算机系统用32位整数存储时间。

下面我将为您详细解释这个问题的来龙去脉：

在计算机的底层，为了节省宝贵的存储空间和计算资源，很多操作系统（尤其是类Unix系统，如Linux、macOS，以及旧版本的Windows）使用一种非常简单的方法来记录时间：

从“纪元时间”开始的秒数：它们将时间存储为从一个固定起点（称为“纪元”）开始所经过的秒数。这个起点通常定义为 UTC时间1970年1月1日0时0分0秒。
使用32位有符号整数：这个“秒数”被存储在一个32位（32-bit）的有符号整数（signed int）变量中。

一个32位的有符号整数，其数值范围是有限的：

让我们来计算一下：

在计算机中，这会导致“整数溢出”。对于有符号整数，溢出后数值会“翻转”成它能表示的最小值，也就是 -2147483648。

这个关键的溢出时刻发生在：
UTC时间2038年1月19日星期二 03:14:07

系统会误以为当前时间是 1901年12月13日 20:45:52（从1970年往回数2147483648秒）。

操作系统和软件（如设置日期时间的程序）知道这个底层限制。为了防止用户将时间设置到一个会引发溢出和不可预测行为的日期，它们通常会人为地将可选择的日期范围限制在2038年1月19日之前。

这是一种保护措施，避免普通用户在不了解技术细节的情况下，无意中将系统时间设置为一个会导致严重错误的日期。

这不仅仅是手机和电脑的问题：所有使用32位系统时间戳的嵌入式系统都可能受影响，例如：旧的路由器、工业控制系统、物联网设备、汽车电子系统等。这些设备生命周期长，很可能在2038年时仍在运行。
解决方案：向64位时间戳过渡
解决这个问题的方法很直接：使用64位整数来存储时间。
- 一个64位有符号整数可以表示的时间范围大到难以想象，大约是从公元前2920亿年到公元2920亿年——这远远超过了宇宙的年龄，可以说是一劳永逸地解决了这个问题。
- 现代的操作系统（如64位的Linux、macOS、Windows 10/11）和编程语言都已经支持或正在全面转向64位的时间存储方式。
为什么我们还在谈论它？
- 遗留系统：世界上仍有大量的旧软件和旧设备在运行，这些系统可能没有更新或无法更新。
- 文件格式和协议：某些文件格式（如ZIP压缩包格式）或网络通信协议中可能仍然定义了32位的时间戳字段。更新所有这些标准需要时间。
- 兼容性：确保新系统能正确处理旧软件中的32位时间戳也是一个挑战。

方面	解释
问题名称	2038年问题（Year 2038 Problem）
根本原因	使用32位有符号整数存储从1970-01-01算起的秒数。
临界点	2038年1月19日 03:14:07 UTC
后果	时间溢出，系统时间跳回1901年，导致依赖时间的软件和系统功能异常甚至崩溃。
设备限制原因	操作系统和软件为防止用户误设而采取的保护性限制。
解决方案	在软件和操作系统中广泛采用64位时间戳。