2038 년에 대비하려면 어떻게해야합니까?

2038 년에 대비하려면 어떻게해야합니까?

---

오늘 작성중인 소프트웨어 중 일부는 30 년 후에 사용될 것이라고 생각하고 싶습니다. 그러나 나는 또한 그것의 많은 부분이 1970 년 이후의 초 수로 시간을 노출하는 UNIX 전통에 기반을두고 있음을 알고 있습니다.

#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
• 2038 년 1 월 19 일 화요일 03:14:07
• 1901 년 12 월 13 일 금요일 20:45:52

ctime (), gmtime () 및 localtime () 함수는 모두 Epoch (1970 년 1 월 1 일 00:00:00 UTC, 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));
    }
}

• Wed Dec 31 16:00:00 PST 1969
• 2008 년 8 월 30 일 토요일 12:02:40 PDT
• 8 월 16 일 토요일 23:12:55 PST 292278994
• 일요일 12 월 02 08:47:04 PST 292269055

하지만 292278994 년은 어떨까요?

---

32 비트 시스템에서도 64 비트 시간을 사용하는 time.h (현재는 localtime (), gmtime (), mktime () 및 timegm ())에 대한 이식 가능한 대체를 작성했습니다. time.h를 대체하기 위해 C 프로젝트에 드롭하기위한 것입니다. Perl에서 사용되고 있으며 Ruby와 Python의 2038 문제도 수정하려고합니다. 이는 +/- 2 억 9,200 만 년의 안전 범위를 제공합니다.

코드 는 y2038 프로젝트에서 찾을 수 있습니다 . 문제 추적기에 질문을 게시하십시오 .

"이것이 앞으로 29 년 동안 문제가되지 않을 것"에 관해서는이 표준 답변 목록을 숙독하십시오 . 요컨대, 일이 미래에 일어나고 때로는 언제 알 필요가 있습니다. 나는 또한 문제, 해결책이 아닌 것, 무엇이 .

아, 그리고 많은 시간 체계가 1970 년 이전의 날짜를 처리하지 않는다는 것을 잊지 마십시오. 1970 년 이전에 일이 일어났습니다. 때때로 당신은 언제를 알아야합니다.

---

항상 RFC 2550을 구현 하고 영원히 안전 할 수 있습니다 ;-)

알려진 우주에는 유한 한 과거와 미래가 있습니다. 우주의 현재 나이는 [Zebu]에서 10 ** 10에서 2 * 10 ** 10 년 사이로 추정됩니다. 우주의 죽음은 [Nigel]에서 10 ** 11 년에 발생하고 [Drake]에서 닫힌 우주 (큰 위기)의 경우 10 ** 12 년 또는 10 ** 14 년에 발생하는 것으로 추정됩니다. 열린 우주 (우주의 열사).

 

Y10K 준수 프로그램은 지원하는 날짜 범위를 우주의 예상 수명과 일치하는 날짜로 제한하도록 선택할 수 있습니다. Y10K 호환 시스템은 10 ** 12 년 전부터 10 ** 20 년 후까지의 Y10K 날짜를 허용해야합니다. Y10K 호환 시스템은 과거와 미래의 최소 10 ** 29 년의 날짜를 수락해야합니다 (SHOULD).

---

Visual Studio moved to a 64 bit representation of time_t in Visual Studio 2005 (whilst still leaving _time32_t for backwards compatibility).

As long as you are careful to always write code in terms of time_t and don't assume anything about the size then as sysrqb points out the problem will be solved by your compiler.

---

I think that we should leave the bug in. Then about 2036 we can start selling consultancy for large sums of money to test everything. After all isn't that how we successfully managed the 1999-2000 rollover.

I'm only joking!

I was sat in a bank in London in 1999 and was quite amazed when I saw a consultant start Y2K testing the coffee machine. I think if we learnt anything from that fiasco, it was that the vast majority of software will just work and most of the rest won't cause a melt down if it fails and can be fixed after the event if needed. As such, I wouldn't take any special precautions until much nearer the time.

---

Given my age, I think I should pay a lot into my pension and pay of all my depts, so someone else will have to fit the software!

Sorry, if you think about the “net present value” of any software you write today, it has no effect what the software does in 2038. A “return on investment” of more than a few years is uncommon for any software project, so you make a lot more money for your employer by getting the software shipped quicker, rather than thinking that far ahead.

The only common exception is software that has to predict future, 2038 is already a problem for mortgage quotation systems.

---

Keep good documentation, and include a description of your time dependencies. I don't think many people have thought about how hard this transition might be, for example HTTP cookies are going to break on that date.

---

What should we do to prepare for 2038?

Hide, because the apocalypse is coming.

But seriously, I hope that compilers (or the people who write them, to be precise) can handle this. They've got almost 30 years. I hope that's enough time.

At what point do we start preparing for Y10K? Have any hardware manufacturers / research labs looked into the easiest way to move to whatever new technology we'll have to have because of it?

---

I work in embedded and I thought I would post our solution here. Our systems are on 32 bits, and what we sell right now has a warantee of 30 years which means that they will encounter the year 2038 bug. Upgrading in the future was not a solution.

To fix this, we set the kernel date 28 years earlier that the current date. It's not a random offset, 28 years is excatly the time it will take for the days of the week to match again. For instance I'm writing this on a thursday and the next time march 7 will be a thursday is in 28 years.

Furthermore, all the applications that interact with dates on our systems will take the system date (time_t) convert it to a custom time64_t and apply the 28 years offset to the right date.

We made a custom library to handle this. The code we're using is based off this: https://github.com/android/platform_bionic

Thus, with this solution you can buy yourself an extra 28 years easily.

---

By 2038, time libraries should all be using 64-bit integers, so this won't actually be that big of a deal (on software that isn't completely unmaintained).

COBOL programs might be fun though.

---

Operative word being "should".

If you need to ensure futureproofing then you can construct your own date/time class and use that but I'd only do that if you think that what you write will be used on legacy OS'

참고URL : https://stackoverflow.com/questions/36239/what-should-we-do-to-prepare-for-2038