这是我第二个关于 DateTime 的问题。我们测试了我们的应用程序，以找出所有已知的错误可能性。一年前我遇到了这个问题，经过大量研究后，我发布了一个CodeProject 上的文章关于这个话题。本文将解释 2038 年漏洞是什么，以及它如何影响我们明天的许多应用程序。解释 2038 年漏洞的全部细节超出了这个问题的范围，所以我参考了一篇我自己写的文章。
链接文字：http://www.codeproject.com/KB/bugs/The-Year-2038-Bug.aspx
我们目前正在使用的哪些应用程序（服务器应用程序、客户端应用程序、基础设施解决方案软件和硬件）容易受到此漏洞的影响？
2038 年漏洞的解决方案是什么？如何升级我们的解决方案和应用程序来解决这个问题？
这个问题很有未来性，但值得讨论。
答案1
我认为小型嵌入式系统面临的风险最大。这些小型系统用于运行我们的电梯、GPS 接收器、汽车电脑等。许多此类设备在 2038 年仍会运行，无法“上网”检查固件更新。
答案2
简短的回答是几乎任何 32 位操作系统都使用 unix 时间戳。
一些 32 位版本已修复为使用 64 位时间，但这始终只是一种选择。
类似地，一些 64 位操作系统仍然使用 32 位 time_t，因此仍然可以进行环绕。
在问题出现之前的 30 年里，我认为推测是不明智的。确保任何新事物都使用 64 位时间戳，到 2038 年，使用 32 位时间戳的东西将非常少。
答案3
我有一种感觉，我们的情况比我们想象的要糟糕得多：
到 2038 年，time_t 在大多数系统上当然将是 64 位宽（只要记住我们 30 年前的情况），所以这并不重要。
我认为问题更严重的是许多协议都指定 32 位时间戳作为其内部工作的一部分。NTP、SSL - 选择你的选择。
即使世界已经发生变化并且每个人都在使用 64 位机器，这些协议肯定仍在使用（SMTP 是在大约 30 年前推出的，现在仍然被广泛使用，而当时推出的硬件并没有那么使用 - 只是为了说明这一点）。
答案4
我们目前正在使用的哪些应用程序（服务器应用程序、客户端应用程序、基础设施解决方案软件和硬件）容易受到此漏洞的影响？
硬件通常不会受到直接影响，大多数实时时钟芯片在 unix 时间下无法工作。即使它们可以工作，也有相对简单的解决方法。这首先是一个软件问题。
大多数 32 位类 Unix 系统及其上运行的应用程序都受到严重影响。它们以 32 位 time_t 作为平台 ABI 的核心组件。
64 位类 Unix 系统通常使用 64 位时间作为其主要表示，因此它们不会受到那么严重的影响，但由于使用错误的数据类型传递时间的草率代码或围绕 32 位 Unix 时间设计的文件格式，仍然可能产生一些影响。
2038 年漏洞的解决方案是什么？
常规解决方案是将 32 位时间替换为 64 位时间。这有多难取决于具体情况。如果它只是一个内部变量或参数，没有在任何稳定的外部 ABI 上公开，那么修复起来相当容易。
另一方面，如果没有“标志日”（即必须立即重建所有内容，或者创建两个具有完全独立的库集的旧版软件和当前软件的独立世界），就很难在平台 ABI 中替换它。
它可以通过类似于大文件支持的方法来实现，但是时间通过平台库传播的范围比文件大小要大得多。
对于文件格式，可能需要一个过渡期。首先定义新版本的格式，然后需要升级软件以读取新格式。最后软件需要开始以新格式写入文件。
在某些情况下，替代解决方案可能是坚持使用 32 位但更改时间窗口，例如，如果您知道您的系统不会有任何 1970 年之前的时间戳并且不使用负数作为标志值，则您可以选择移动到 32 位无符号量。
如何升级我们的解决方案和应用程序来解决这个问题？
对于全尺寸服务器，您可能已经运行了 64 位操作系统，因此基本底层平台内容应该已经存在，您可以专注于查找应用程序中的问题。启动具有未来日期的服务器，看看会出现什么问题。
对于运行 64 位操作系统不合理甚至不可能的嵌入式产品来说，情况看起来并不乐观。除非/除非主要的上游库和发行版能够解决问题，否则很难在应用程序级别做任何事情。