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

StackOverflow https://stackoverflow.com/questions/36239

题

我想我今天编写的一些软件将在 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);
}

执行结果为：

  • 1970 年 1 月 1 日星期四 00:00:00
  • 2008 年 8 月 30 日星期六 18:37:08
  • 1 月 19 日星期二 03:14:07 2038
  • 12 月 13 日星期五 20:45:52 1901

函数 ctime()、gmtime() 和 localtime() 都将时间值作为参数，表示自纪元以来的时间（以秒为单位）（00:00:00 UTC，1970 年 1 月 1 日；参见时间(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));
    }
}
  • 1969 年 12 月 31 日星期三 16:00:00（太平洋标准时间）
  • 2008 年太平洋夏令时间 8 月 30 日星期六 12:02:40
  • 太平洋标准时间 8 月 16 日星期六 23:12:55 292278994
  • 太平洋标准时间 12 月 2 日星期日 08:47:04 292269055

但是292278994年呢？

有帮助吗？

解决方案

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

你可以找到代码 在 2038 年项目中. 。如有任何问题，请随时发帖至 问题跟踪器.

至于“这在接下来的 29 年里都不会成为问题”，请仔细阅读这篇文章 标准答案列表 对此。简而言之，事情会在未来发生，有时你需要知道什么时候发生。我也有 关于问题的介绍，什么不是解决方案，什么是解决方案.

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

其他提示

您可以随时实施 RFC 2550 并永远安全;-)

已知的宇宙有有限的过去和未来。在[Zebu]中估计宇宙的当前年龄在10 ** 10到2 * 10 ** 10年之间。在[奈杰尔]中估计宇宙的死亡将在10 ** 11年内发生，并且在[Drake]中发生在10 **在封闭的宇宙中发生12年（大脆脆）或10 ** 14年开放的宇宙（宇宙的热死亡）。

 

符合Y10K的程序可能会选择将其支持的日期范围限制为与宇宙预期寿命一致的人。符合Y10K的系统必须接受Y10K的日期，从过去的10 **到未来20年的10 **。符合Y10K的系统应在过去和未来至少接受10 ** 29年的日期。

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

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

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

我只是在开玩笑！

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

操作词是“应该”。

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

许可以下： CC-BY-SA 和 归因
不隶属于 StackOverflow
scroll top