2038年的问题[关闭]

2038年问题极有可能出现问题吗？

我在嵌入式Linux系统中遇到了此问题，该系统需要处理某些长期加密证书中的2038年以后的日期，因此我想说，这种可能性取决于您的应用程序域。

尽管大多数系统应该在2038年之前就已经准备就绪，但是如果您今天发现自己计算的日期很长，那么您可能会遇到问题。

我认为这将是一个重要的问题，比1999/2000的Y2K问题更加有害，因为受影响的代码通常是较低级别的（它是CTIME），因此很难确定以这种方式存储时间的地方。

更复杂的是，Y2K被认为是潮湿的爆管，这将使在比赛开始前更加难以引起人们对问题的关注。

文化参考：

Cory Doctorow正在尝试一种新的模式，用于在开放许可下进行短篇小说创作/出版，我建议其中一个2038年主题，他在大纪元曾做得很出色：http：//craphound.com/？ p = 2337

几年前，已经有问题的报告，例如按揭计划对30年期贷款进行计算的领域：2008 + 30 = 2038。

最终，64位操作系统与2037问题无关。（与2038年相比，CTIME用尽的时间更接近2037年）。

问题不是操作系统的位深度，而是操作系统如何存储时间。或数据库列如何选择存储时间。或者，该目录如何服务时间语法属性在后端存储时间。

这是一个比人们想象的要大得多的问题，因为使用32位时间计数器非常普遍且普遍。

每个存储时间的实例都需要重新访问，所有API都要更新，所有使用它的工具也要更新。

通过抽象层，您可以通过一种人类可读的时间格式来设置时间，而不是通过写出原始数据来简化设置，但这只是一种情况。

我怀疑这会比大多数人想的要大得多。

这是我的看法，但是此问题是由于32位计数器问题引起的，今天大多数操作系统已更新为可以处理64位（至少在64位计算机上）的时间，因此我想所有操作系统和软件都可以长期准备就绪假设在2038年之前的2020年。因此，只有在2038年您仍将运行2020年以后的软件时，
您才可能有问题。在几乎所有情况下，这都不是问题。我希望。

没什么大不了的。

在第一次Y2K闪电战中，要求软件和硬件供应商将其产品认证为“符合Y2K要求”才能出售（我记得PC Connection上的网络电缆已通过Y2K认证），许多公司对所有内容进行了详细的审核，可以在以后设置时钟并进行测试。

当时，由于测试成本很高，因此他们几乎总是用多个日期进行测试，例如1/1/99（某些开发人员可能使用99作为标记），12/31 / 99、1 / 1 / 00、2000年的飞跃，1/19/38等。看到这里一个乏味的清单。

因此，我相信1999年左右的任何重要软件都可能没有2038个错误，但是此后由无知的程序员编写的新软件可能会出现。在整个Y2K崩溃之后，程序员通常对日期编码问题有了更多的了解，因此影响不会像Y2K那样大（这本身就是一种反高潮）。

届时仍在运行的32位系统将是一个问题。

#include <time.h>
#include <stdio.h>

int main() {
  time_t t = (time_t)(1L << (sizeof(time_t)*8 - 9));
  printf("%d\n", sizeof(time_t));
}

它应该是1而不是9，但是ctime不能处理更大的日期：

8 - Sun Jun 13 07:26:08 1141709097

我的系统（当然是64位）时间甚至可以运行一百万年。解决方案是将系统更新为64位。

问题是程序可能无法处理它。尤其是老旧的，专有的并且没有维护。开发人员习惯于以下事实：

• int是32位（实际上，在其他64位系统上，它们保留为32位，因为假定它们始终是32位）
• 大多数类型（例如time_t）都可以安全地转换为int

在流行的FLOSS软件中，这两种情况都可能无法通过“多眼”审查。在较不流行和专有的地方，它将主要取决于作者。

我猜在自由* nix世界上，“ 2038”会被“忽略”，而我确实希望“专业”平台（即拥有大量专有软件的平台）上出现问题-尤其是如果某些关键部分无法维护的话。

如果它像Y2K之类的东西，有些人已经受到影响并且正在更改软件，但是大多数开发人员将忽略它，直到2030年代的某个时候，大概是2035年左右，那时将完成许多工作，并且年龄足够大的人知道K＆R C并且还不太老的人会突然能够签下很多钱。实际的过渡将显示许多尚未完成的事情，可能没有那么重要的事情。

Y2K问题是代表一年的两个章程，而不是四个。

许多系统无法区分2000和1900，因为它们只存储了'00'。

几乎所有系统现在要么使用4个字符来存储年份，要么使用某种类型的库。

因此，让所有人都担心10000年（Y10K）。除了操作系统和库编写器...