unix - 迎接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);
}

执行结果:

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

The functions ctime(), gmtime(), and localtime() all take as an argument a time value representing the time in seconds since the Epoch (00:00:00 UTC, January 1, 1970; see 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));
    }
}

• 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 年呢？

Answer 1

我已经编写了 time.h 的可移植替代品(目前只有 localtime()、gmtime()、mktime() 和 timegm())，即使在 32 位机器上也使用 64 位时间。它旨在作为 time.h 的替代品放入 C 项目中。它正在 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 年之前，有时您需要知道时间。