迎接2038年我们应该做什么准备？

Question

我想我今天编写的一些软件将在 30 年后被使用。 但我也知道其中很多都是基于 UNIX 传统，将时间公开为自 1970 年以来的秒数。

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

void print(time_t rt) {
    struct tm * t = gmtime(&rt);
    puts(asctime(t));
}

int main() {
    print(0);
    print(time(0));
    print(LONG_MAX);
    print(LONG_MAX+1);
}

执行结果为：

• Thu Jan 1 00:00:00 1970
• Sat Aug 30 18:37:08 2008
• Tue 1 月 19 日 03:14:07 2038
• 12 月 13 日星期五 20:45:52 1901

<块引用>

函数 ctime()、gmtime() 和 localtime() 都将时间值作为参数，表示自纪元（1970 年 1 月 1 日 00:00:00 UTC，1970 年 1 月 1 日）以来的时间（以秒为单位）；请参阅 time(3 ））。

我想知道作为程序员在这个领域是否有什么积极主动的事情要做，或者我们是否相信所有软件系统（又名操作系统）将来都会神奇地升级？

更新 看来 64 位系统确实是安全的：

import java.util.*;

class TimeTest {
    public static void main(String[] args) {
        print(0);
        print(System.currentTimeMillis());
        print(Long.MAX_VALUE);
        print(Long.MAX_VALUE + 1);
    }

    static void print(long l) {
        System.out.println(new Date(l));
    }
}

• Wed Dec 31 16:00:00 PST 1969
• Sat Aug 30 12:02:40 PDT 2008
• Sat Aug 16 23:12:55 PST 292278994
• Sun Dec 02 08:47:04 PST 292269055

但是年份 292278994 又如何呢？

Answer 1

到 2038 年，时间库应该全部使用 64 位整数，因此这实际上并不是什么大问题（在并非完全无人维护的软件上）。

不过，COBOL 程序可能很有趣。

Answer 2

操作词是“应该”。

如果您需要确保面向未来，那么您可以构建自己的日期/时间类并使用它，但只有当您认为您编写的内容将在旧操作系统上使用时我才会这样做

Answer 3

Visual Studio 在 Visual Studio 2005 中迁移到 time_t 的 64 位表示形式（同时仍保留 _time32_t 以实现向后兼容性）。

只要您始终小心地根据 time_t 编写代码并且不要假设任何有关大小的信息，那么正如 sysrqb 指出的那样，您的编译器将解决该问题。

Answer 4

我已经编写了 time.h 的可移植替代品（目前只有 localtime()、gmtime()、mktime() 和 timegm()），即使在 32 位机器上也使用 64 位时间。 它旨在作为 time.h 的替代品放入 C 项目中。 它正在 Perl 中使用，我也打算用它修复 Ruby 和 Python 的 2038 问题。 这为您提供了 +/- 2.92 亿年的安全范围。

您可以在 y2038 项目找到代码。 请随时将任何问题发布到问题跟踪器。

至于“这在接下来的 29 年里都不会成为问题”，请仔细阅读关于该问题的演示，什么不是解决方案，以及什么是。

哦，不要忘记，许多时间系统不处理 1970 年之前的日期。事情发生在 1970 年之前，有时您需要知道时间。

Answer 5

您始终可以实施 RFC 2550 并永远安全;-)

已知的宇宙有有限的过去和未来。 目前年龄
[Zebu] 中的宇宙估计介于 10 ** 10 和 2 * 10 ** 之间
10年。 宇宙死亡预计将在[奈杰尔]发生
在 10 ** 11 - 年和 [Drake] 中发生在 10 ** 12
封闭宇宙（大挤压）需要 10 年，或者 10 ** 14 年
开放宇宙（宇宙的热寂）。

 

万年历兼容计划可能会选择限制其日期范围
支持那些与宇宙预期寿命一致的人。
符合 Y10K 的系统必须接受 10 ** 12 年的 Y10K 日期
过去到未来10**20年。 符合 Y10K 的系统
应接受过去至少 10 ** 29 年的日期，并且
未来。

Answer 6

请注意，我在 32 位 MCU 上遇到了您的帖子，并使用我的编译器运行了您的代码，这也产生了 1970 的溢出，并错误地认为我需要像 y2038 项目中的库一样的库。

然而，应该这样做来验证（注意 time_t 转换）：

printtime(0);
printtime(time(0));
printtime(((time_t)LONG_MAX));
printtime(((time_t)LONG_MAX)+1);

在我的例子中，time_t 实际上被定义为 __int_least64_t => uint64_t，并且本机 gmtime 函数采用 64 位作为输入，因此在 2038 年之后工作得很好。
但是，当不进行转换时，我的编译器确实打印了一条我愚蠢地错过的警告：

“long int”类型表达式中的整数溢出导致“-2147483648”[-Woverflow]

请注意，仅将大小写转换为 (uint32_t) 也足够了，但如果不进行转换，编译器会将 LONG_MAX+1 作为有符号 int 执行，从而导致溢出。 只有之后编译器才会将-1结果转换为调用函数的time_t，这仍然是错误的。 令人困惑的是，这似乎表明 gmtime 不是 64 位，但这是一个错误的结论

长话短说：我的 libc 时间函数已经是 64 位（即使在 32 位 MCU 上），但你的帖子失败了，思考我需要额外的库（这是不需要的）。 （基本上相当于 y2038 代码已经在那里了）

Answer 7

保留良好的文档，并包含对时间依赖性的描述。 我认为很多人都没有想过这种转变有多困难，例如 HTTP cookie 将在该日期失效。

Answer 8

我们应该为 2038 年做哪些准备？

躲起来，因为世界末日即将来临。

但说真的，我希望编译器（或者准确地说是编写它们的人）能够处理这个问题。 他们已经快30年了。 我希望时间足够。

我们从什么时候开始为万年做准备？ 是否有任何硬件制造商/研究实验室研究过最简单的方法来转向我们因此而必须拥有的任何新技术？

Answer 9

我认为我们应该保留这个 bug。然后到 2036 年左右我们就可以开始以大笔资金出售咨询服务来测试一切。 毕竟，这并不是我们成功管理 1999-2000 年过渡的方式。

我只是在开玩笑！

1999 年，我坐在伦敦的一家银行，当我看到一位顾问开始 Y2K 测试咖啡机时，我感到非常惊讶。 我认为，如果我们从这次惨败中学到了什么的话，那就是绝大多数软件都能正常工作，其余大部分软件如果失败也不会导致崩溃，并且可以在需要时在事件发生后修复。 因此，除非您正在处理一个非常关键的软件，否则我不会在临近时间之前采取任何特殊的预防措施。

Answer 10

我从事嵌入式工作，我想我应该在这里发布我们的解决方案。 我们的系统是32位的，我们现在卖的有30年的保修期，这意味着他们会遇到2038年的bug。 以后升级也不是解决办法。

为了解决这个问题，我们将内核日期设置为比当前日期早 28 年。 这不是随机偏移，28 年正是一周中的日期再次匹配所需的时间。 例如，我在星期四写这篇文章，而下一次 3 月 7 日是星期四是 28 年后的事了。

此外，所有与我们系统上的日期交互的应用程序都会将系统日期 (time_t) 转换为自定义 time64_t，并将 28 年偏移量应用到正确的日期。

我们制作了一个自定义库来处理这个问题。 我们使用的代码基于此：https://github.com/android/platform_bionic

因此，通过此解决方案，您可以轻松为自己赢得额外的 28 年寿命。

Answer 11

考虑到我的年龄，我认为我应该支付很多养老金并支付我所有部门的费用，所以其他人将不得不安装该软件！

抱歉，如果你考虑一下你今天编写的任何软件的“净现值”，它对 2038 年软件的功能没有影响。对于任何软件项目来说，超过几年的“投资回报”都是罕见的，所以通过更快地交付软件，您可以为雇主赚更多的钱，而不是想得太远。

唯一常见的例外是必须预测未来的软件，2038 年对于抵押贷款报价系统来说已经是一个问题。