2038年我们应该做哪些准备? [英] What should we do to prepare for 2038?

问题描述

我想我今天编写的一些软件将在 30 年后使用.但我也知道，其中很多都是基于 UNIX 传统，将时间表示为自 1970 年以来的秒数.

#include #include #include 无效打印(time_t rt){struct tm * t = gmtime(&rt);puts(asctime(t));}int main() {打印(0)；打印(时间(0))；打印(LONG_MAX)；打印(LONG_MAX+1)；}

执行结果:

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

<块引用><块引用>

函数 ctime()、gmtime() 和 localtime() 都将时间值作为参数，该时间值表示自 Epoch 以来的时间(00:00:00 UTC，1970 年 1 月 1 日；参见 time(3)) ).

我想知道作为程序员在这方面是否有任何积极的事情要做，或者我们是否相信所有软件系统(也称为操作系统)在未来都会神奇地升级?

更新 看来 64 位系统确实可以避免这种情况:

import java.util.*;类时间测试{公共静态无效主(字符串 [] args){打印(0)；打印(System.currentTimeMillis())；打印(Long.MAX_VALUE)；打印(Long.MAX_VALUE + 1)；}静态无效打印(长 l){System.out.println(new Date(l));}}

• 1969 年 12 月 31 日星期三 16:00:00 PST
• 太平洋夏令时间 2008 年 8 月 30 日星期六 12:02:40
• 太平洋标准时间 8 月 16 日星期六 23:12:55 292278994
• 太平洋标准时间 12 月 2 日星期日 08:47:04 292269055

但是 292278994 年呢?

解决方案

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

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

至于再过 29 年都不会成为问题"，请仔细阅读此 标准答案列表.简而言之，事情会在未来发生，有时你需要知道什么时候发生.我也有关于问题的演示，什么不是解决方案，什么是是.

哦，别忘了许多时间系统不处理 1970 年之前的日期.事情发生在 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);
}

Execution results in:

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

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?

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));
    }
}

• 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

But what about the year 292278994?

解决方案

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.

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

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.

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屋！