查看“2038 年问题”的源代码

[[文件:Year_2038_problem.gif|thumb|400px|2038 年问题演示，第一行是 {{code|time_t}} 数字的二进制表示；第二行是十进制表示；第三行是受影响的计算机理解的时间；第四行是实际时间]]
2038 年问题是一种计算机日期范围问题。在计算机应用上，2038 年问题可能会导致某些软件在 2038 年 1 月 19 日 3 时 14 分 07 秒之后无法正常工作。所有使用 POSIX 时间表示时间的程序都会受到 2038 年问题的影响，这是因为这些程序是以自 1970 年 1 月 1 日开始经过的秒数（忽略闰秒）表示时间。这种时间表示法在类 Unix 操作系统之中是标准，影响使用 C 语言开发其他大部分操作系统使用的软件。

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

在少数情况下，在当制定规格时，特别规定以无正负号的 32 位整数存储 POSIX 时间{{efn|在使用无正负号 32 位整数的情况下，对应十进制范围是 {{code|0}}~{{code|4294967295}}，绝对值可用值总数为 {{code|4294967296}}（{{code|0}} 也单独计算为一个数）}}，因此相同的错误会被延后到 2106 年 2 月 7 日 14 时 28 分 15 秒（{{code|4294967295}}）。例如比特币区块链中的区块时间戳，就是以这种方法存储。

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

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

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

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

== 注 ==
{{notelist}}

[[分类:扩展词条]]