加入收藏 | 设为首页 | 会员中心 | 我要投稿 李大同 (https://www.lidatong.com.cn/)- 科技、建站、经验、云计算、5G、大数据,站长网!
当前位置: 首页 > 综合聚焦 > 服务器 > 安全 > 正文

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

发布时间:2020-12-15 16:33:59 所属栏目:安全 来源:网络整理
导读:我想认为,我今天撰写的一些软件将在30年内使用。但我也知道,很多是基于UNIX的传统,将时间作为自1970年以来的秒数。 #include stdio.h#include time.h#include limits.hvoid print(time_t rt) { struct tm * t = gmtime(rt); puts(asctime(t));}int main()
我想认为,我今天撰写的一些软件将在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年之前,有时你需要知道什么时候。

(编辑:李大同)

【声明】本站内容均来自网络,其相关言论仅代表作者个人观点,不代表本站立场。若无意侵犯到您的权利,请及时与联系站长删除相关内容!

    推荐文章
      热点阅读