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
2008年8月30日星期六18:37:08
Tue Jan 19 03:14:07 2038
Fri Dec 13 20:45:52 1901

函数ctime（），gmtime（）和localtime（）都将一个时间值作为参数，该时间值表示自Epoch（1970年1月1日00:00:00 UTC;参见时间（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
2008年8月30日星期六12:02:40 PDT 2008
8月16日星期六23:12:55太平洋标准时间 292278994
太阳12月02日08:47:04太平洋标准时间 292269055

但292278994年呢？

Answer 1

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

您可以找到代码at the y2038 project。请随时将任何问题发布到issue tracker。

关于“这不会成为另一个29年的问题”，请仔细阅读list of standard answers。简而言之，事情发生在未来，有时你需要知道什么时候。我也有a presentation on the problem, what is not a solution, and what is。

哦，不要忘记很多时间系统都没有处理1970年以前的日期。东西发生在1970年之前，有时你需要知道什么时候。

Answer 2

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

已知的宇宙具有有限的过去和未来。目前的年龄在[Zebu]估计宇宙在10 ** 10和2 * 10之间** 10年。宇宙的死亡在[Nigel]中估计会发生在10 ** 11年和[德雷克]中发生10 ** 12 一个封闭的宇宙（大的紧缩）或10 ** 14年的一年开放的宇宙（宇宙的热死亡）。

符合Y10K的程序可以选择限制它们的日期范围支持符合宇宙预期寿命的人。符合Y10K标准的系统必须接受10年至12年的Y10K日期过去到未来10 ** 20年。符合Y10K标准的系统我们应该接受过去至少10 ** 29年的日期将来

Answer 3

Visual Studio在Visual Studio 2005中移动到64位表示time_t（同时仍然留下_time32_t以便向后兼容）。

只要你小心总是按照time_t编写代码并且不假设大小，那么sysrqb指出问题将由编译器解决。

Answer 4

我认为我们应该留下这个漏洞。然后大约在2036年，我们可以开始出售大量资金的咨询服务来测试一切。毕竟不是我们如何成功地管理1999-2000翻转。

我只是在开玩笑！

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

Answer 5

鉴于我的年龄，我认为我应该为我的退休金支付很多费用并支付我所有的费用，所以其他人将不得不适应这个软件！

很抱歉，如果你考虑一下你今天写的任何软件的“净现值”，它对2038年该软件的作用没有任何影响。任何软件都不会有超过几年的“投资回报”。项目，所以你可以通过更快地运送软件为你的雇主赚更多钱，而不是考虑那么远。

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

Answer 6

保留良好的文档，并包含时间依赖性的描述。我认为很多人都没有想过这种过渡会有多么困难，例如HTTP cookie将在那个日期破解。

Answer 7

我们应该怎么做才能为2038做准备？

隐藏，因为天启即将到来。

但严重的是，我希望编译器（或编写它们的人，确切地说）可以处理这个问题。他们已经差不多30年了。我希望有足够的时间。

我们在什么时候开始准备Y10K？有没有任何硬件制造商/研究实验室研究最简单的方法来转向我们必须拥有的任何新技术？

Answer 8

我在嵌入式工作，我想我会在这里发布我们的解决方案。我们的系统是32位，我们现在卖的是30年的保证，这意味着他们将遇到2038年的错误。未来的升级不是解决方案。

要解决此问题，我们将内核日期设置为当前日期的28年。这不是一个随机的偏移，28年是令人兴奋的时间，一周中的几天再次匹配。例如，我是在星期四写这篇文章，下一次3月7日星期四将是28年。

此外，与我们系统上的日期交互的所有应用程序将采用系统日期（time_t）将其转换为自定义时间64_t，并将28年偏移量应用于正确的日期。

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

因此，使用此解决方案，您可以轻松地为自己购买额外的28年。

Answer 9

到2038年，时间库都应该使用64位整数，所以这实际上并不是那么大的交易（对于不完全没有维护的软件）。

COBOL程序可能很有趣。

Answer 10

操作词是“应该”。

如果你需要确保未来的防御，那么你可以构建自己的日期/时间类并使用它，但我只会这样做，如果你认为你写的东西将用于旧版操作系统

我们该怎么做才能为2038做准备？

10 个答案: