有人对 2038 time_t 错误做任何事情吗？ [复制]答案

【问题标题】：is anybody doing anything about 2038 time_t bug? [duplicate]有人对 2038 time_t 错误做任何事情吗？ [复制]
【发布时间】：2010-10-12 20:54:52
【问题描述】：

可能重复：
What should we do to prepare for 2038?

我不是指抽象的“人”。我的意思是你在做什么，如果是的话怎么办？

我是一位古老的程序员，我记得我在 70 年代后期编写 COBOL 时对我团队中的其他人说“你知道 - 这在 2000 年行不通”。对此的回答是“是的，但到那时这个系统将无法使用，那是 25 年后”。

2038 年还有 28 年。

【问题讨论】：

2012 年之后是 2038 年吗？是的？第一件事，伙计。
请将此问题设为社区 wiki 问题。正确的答案可能是“我酗酒”。或者正确的答案可能是这是一个次要的操作系统问题。 Windows 会没了，64 位 Linux 内核就不会有这个问题了。
可能重复：What should we do to prepare for 2038?
怎么样 - 我会推雏菊？
什么都不做会让你在 28 年后找到工作；）

标签： c++ c unix time

【解决方案1】：

我在我的软件的发行说明中添加了免责声明：Best before 2038.

【讨论】：

【解决方案2】：

为下一波昂贵的咨询工作祈祷并做好准备。正好赶上退休！

【讨论】：

【解决方案3】：

当我需要存储纪元的秒数时，我使用 64 位类型。如果我需要存储时间戳并且存储空间不紧，我将使用 ISO-8601 格式的字符串。

【讨论】：

【解决方案4】：

许多系统使用 64 位 time_t，它在很长一段时间内都不会换行（对于滴答声=秒）。

在我自己的代码中，我只是确保使用具有很长周期的时间表示，或者有时在做嵌入的东西时，我只是设计一些东西，以便通过将我的时间计算限制为相对较小（与可测量的时间长度相比）时间增量。

【讨论】：

【解决方案5】：

我认为，最简单的方法是编写易于维护的软件。也就是说，数据模型和在其上运行的算法之间的低耦合。大多数 DBMS 和计算机语言已经设计为支持这种抽象。

【讨论】：