我们应该为2038年做些什么呢? [英] What should we do to prepare for 2038?

问题描述

我想我今天编写的某些软件将在30年内使用.但是我也知道，很多时间都是基于UNIX的传统，即将时间公开为自1970年以来的秒数.

I would like to think that some of the software I'm writing today will be used in 30 years. But I am also aware that a lot of it is based upon the UNIX tradition of exposing time as the number of seconds since 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

• 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

函数ctime()，gmtime()和localtime()都将一个时间值作为参数，该时间值表示自纪元(1970年1月1日UTC，00:00:00；请参见time(3) )).

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) ).

我想知道，作为程序员，在这方面是否有任何积极主动的事情要做，还是我们相信将来所有软件系统(又名操作系统)将如何进行神奇的升级?

I wonder if there is anything proactive to do in this area as a programmer, or are we to trust that all software systems (aka Operating Systems) will some how be magically upgraded in the future?

更新:看来，确实64位系统对此是安全的:

Update It would seem that indeed 64-bit systems are safe from this:

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
• Sun Dec 02 02:47:04 PST 292269055
• Wed Dec 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年呢?

But what about the year 292278994?

推荐答案

我编写了可移植的time.h替代品(目前仅使用64位时间的localtime()，gmtime()，mktime()和timegm()).即使在32位计算机上也是如此.打算将其放入C项目中，以代替time.h.它正在Perl中使用，我也打算用它来解决Ruby和Python的2038问题.这为您提供了+/- 2.92亿年的安全范围.

I have written portable replacement for time.h (currently just localtime(), gmtime(), mktime() and timegm()) which uses 64 bit time even on 32 bit machines. It is intended to be dropped into C projects as a replacement for time.h. It is being used in Perl and I intend to fix Ruby and Python's 2038 problems with it as well. This gives you a safe range of +/- 292 million years.

您可以在y2038项目中找到代码 .请随时将任何问题发布到问题跟踪器.

You can find the code at the y2038 project. Please feel free to post any questions to the issue tracker.

关于再过29年这将不再是问题"，请仔细阅读标准答案列表.简而言之，将来会发生某些事情，有时您需要知道何时.我也有关于问题的介绍，什么不是解决方案，以及什么是.

As to the "this isn't going to be a problem for another 29 years", peruse this list of standard answers to that. In short, stuff happens in the future and sometimes you need to know when. I also have a presentation on the problem, what is not a solution, and what is.

哦，别忘了很多时间系统都不处理1970年之前的日期.东西发生在1970年之前，有时您需要知道何时.

Oh, and don't forget that many time systems don't handle dates before 1970. Stuff happened before 1970, sometimes you need to know when.

这篇关于我们应该为2038年做些什么呢?的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！