我在堆栈溢出上看到过很多关于为什么某些代码无法在 2038 年之后运行的问题，但答案通常只建议升级到 64 位操作系统。我的问题是为什么会出现这种情况？是不是和2000年的问题很相似？是否可以使用不同的操作系统来修复该问题，或者 32 位处理器在物理上无法处理 2038 年之后的时间？为什么？ （我是 Linux 新手，所以这可能是一个简单的问题，但我真的不知道答案）。
答案1
Unix 系统的时间是通过自纪元（UTC 1970 年 1 月 1 日 00:00）以来的秒数来跟踪的。到 2038 年，这一秒数将超过 32 位整数的存储能力。这就是 64 位内核解决该问题的原因。引用维基百科:
在许多平台上，表示时间点的 Unix time_t 数据类型是一个有符号整数，传统上为 32 位（但见下文），直接编码 Unix 时间数字，如上一节所述。 32 位意味着它总共涵盖了大约 136 年的范围。最短可表示日期是 1901 年 12 月 13 日星期五，最长可表示日期是 2038 年 1 月 19 日星期二。 UTC 2038-01-19 03:14:07 一秒后，此表示将溢出。人们对这一里程碑的期待既有趣又恐惧——参见 2038 年问题。
在一些较新的操作系统中，time_t 已扩展至 64 位。这将可表示的时间在两个方向上扩展了大约 2930 亿年，这是每个方向宇宙当前年龄的二十倍以上。
进一步阅读这里。
答案2
我的问题是为什么会出现这种情况？
因为32位有符号整数的最大值是2147483647，也就是68年多一点的秒数。因此，从 1970 年开始，有符号 32 位整数计数秒的范围将在 2038 年结束。
是不是和2000年的问题很相似？
从某种意义上说。 Y2K 是关于仅保留两位十进制数字的空间，这是关于仅保留 32 位。
可以用不同的操作系统修复吗
当然。例如，对于 NTFS，Windows 使用 64 位值，自 1601 年起计算 100 ns 刻度；这应该足够到 30828 年了。
或者 32 位处理器实际上无法处理 2038 年之后的时间？
不，只是 32 位数字不够。在32位处理器上运行的程序可以通过使用多个32位字和一些逻辑来处理更大的数字；这就是密码学中所需的大量数字的处理方式。 （我也想知道这种 32 位时间格式是否首先在 32 位或 16 位机器（或一些更奇怪的机器）上使用。）
此时，它“只是”一个兼容性问题，因为许多/大多数现有软件（在 32 位系统上）都采用 32 位时间戳，并且操作系统接口提供了这一点。构建一个使用 64 位时间戳的新系统很容易，但以与旧软件兼容的方式实现这一点则要困难得多。 （但是据我所知，32 位 Linux 上对 64 位时间的支持已经添加，或者正在开发中。）