2038 年问题

2038 年问题是一种计算机日期范围问题。在计算机应用上，2038 年问题可能会导致某些软件在 2038 年 1 月 19 日 3 时 14 分 07 秒之后无法正常工作。所有使用 POSIX 时间表示时间的程序都会受到 2038 年问题的影响，这是因为这些程序是以自 1970 年 1 月 1 日开始经过的秒数（忽略闰秒）表示时间。这种时间表示法在类 Unix 操作系统之中是标准，影响使用 C 语言开发其他大部分操作系统使用的软件。

2038 年问题演示，第一行是 time_t 数字的二进制表示；第二行是十进制表示；第三行是受影响的计算机理解的时间；第四行是实际时间

问题由来

在大部分的 32 位操作系统上，time_t 数据模式使用包括正负号在内的 32 位整数计算的秒数。这个数据是以 32 位存储的，第一位是符号位，其余的 31 位用来存储数字，而这 31 位数字可以存储的最大数字为 2147483647，记录了自 1970 年 1 月 1 日 0 时 0 分 0 秒开始经历的秒数。依据此标准，在此格式下能够被表示的最晚时间是 2038 年 1 月 19 日 3 时 14 分 07 秒（+2147483647）。若超过这个范围，时间将会自动绕回，且在内部被表示为负数（-2147483648），造成程序无法工作，原因在于这些程序无法将时间识别为 2038 年，可能会依照个别实现跳回到 1970 年（1970 年 1 月 1 日 0 时 0 分 0 秒，即 0）或 1901 年（1901 年 12 月 13 日 20 时 45 分 52 秒，即 -2147483648）。由于这种跳回，可能会产生错误的计算及动作，甚至会因此崩溃。

在少数情况下，在当制定规格时，特别规定以无正负号的 32 位整数存储 POSIX 时间，因此相同的错误会被延后到 2106 年 2 月 7 日 14 时 28 分 15 秒（4294967295）。例如比特币区块链中的区块时间戳，就是以这种方法存储。

修复方法

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

大部分 64 位操作系统已经将 time_t 变量更改为 64 位宽。但是其他现有架构改动仍然在进行中，预期可以在 2038 年前完成。许多嵌入式系统仍然在使用 32 位操作系统，相对于一般电脑科技上 18~24 个月的革命性更新，嵌入式系统可能直至使用寿命结束都不会改变。32 位 time_t 的使用也被用于编码文件格式，例如众所周知的 ZIP 文件压缩格式。此问题能够存在的时间远比受影响的设备还要长。

2038 年问题不仅比 2000 年问题更隐蔽，而且比之前 2000 年问题更具有破坏力，这是因为 2000 年问题只会导致应用层的程序出现问题，比如信用卡支付系统，或者管理系统。而 2038 年问题将会影响系统最底层的时间控制的功能。

要解决这个问题，最简单的方式是扩展 Unix 时间的长度，用 64 位数字来表示。64 位运算器使用 64 位二进制数记录，除去表示正负的符号位，它的实际可用位数是 63 位，最大表示到公历的协调世界时（UTC）时间 292277026596 年 12 月 4 日 15 时 30 分 08 秒（+9223372036854775807），此时已经是大约 2922 亿年后了。当然，理想的情况是到 2038 年时，64 位系统已经成为主流，从而避免特意去修正这个问题所需要的大量开销。否则，人们就必须把新的 64 位时间拆分成两部分并分别保存在两个变量里，这是一个麻烦而且效率低下的选择。