2038 年问题：修订间差异

在大部分的 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}}）。例如比特币区块链中的区块时间戳，就是以这种方法存储。

要解决这个问题，最简单的方式是扩展 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 位时间拆分成两部分并分别保存在两个变量里，这是一个麻烦而且效率低下的选择。