unix – 我们应该如何准备2038年？

我想认为，我今天撰写的一些软件将在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 Jan 19 03:14:07 2038
> Fri Dec 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) ).

我不知道在这个领域是否有任何主动做的程序员，或者我们相信所有的软件系统(aka操作系统)将有一些如何神奇升级在未来？

更新它似乎确实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));
    }
}
>星期三12月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？

我写了便携式替换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年之前，有时你需要知道什么时候。

原文链接：https://www.f2er.com/bash/391582.html

unix – 我们应该如何准备2038年？

猜你在找的Bash相关文章