2038년, 우리는 무엇을 준비해야 할까?

StackOverflow https://stackoverflow.com/questions/36239

문제

나는 오늘 내가 쓰고 있는 소프트웨어 중 일부가 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
  • 1월 19일 화요일 03:14:07 2038
  • 12월 13일 금요일 20:45:52 1901

ctime(), gmtime() 및 localtime() 함수는 모두 Epoch(1970년 1월 1일 00:00:00 UTC;시간(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));
    }
}
  • 1969년 12월 31일 수요일 16:00:00 PST
  • 2008년 8월 30일 토요일 12:02:40 PDT
  • 8월 16일 토요일 23:12:55 PST 292278994
  • 12월 2일 일요일 08:47:04 PST 292269055

하지만 292278994년은 어떨까요?

도움이 되었습니까?

해결책

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

코드를 찾을 수 있습니다 y2038 프로젝트에서.궁금한 사항은 언제든지 게시판에 남겨주세요 이슈 트래커.

"이것은 앞으로 29년 동안은 문제가 되지 않을 것이다"에 대해서는 이것을 정독하라 표준 답변 목록 그것에.간단히 말해서, 어떤 일이 미래에 발생하며 때로는 언제 발생하는지 알아야 할 때도 있습니다.나 또한 문제에 대한 프레젠테이션, 해결책이 아닌 것은 무엇인지,.

아, 그리고 많은 시간 시스템이 1970년 이전 날짜를 처리하지 않는다는 사실을 잊지 마세요.1970년 이전에 일어난 일이므로 때로는 언제인지 알아야 할 때도 있습니다.

다른 팁

언제든지 구현할 수 있습니다. RFC 2550 영원히 안전하세요 ;-)

알려진 우주에는 유한한 과거와 미래가 있습니다.우주의 현재 시대는 [Zebu]에서 10 ** 10 ~ 2 * 10 ** 10 세로 추정됩니다.우주의 죽음은 [Nigel]에서 10 ** 11 년과 [드레이크]에서 발생하는 것으로 추정됩니다. 열린 우주 (우주의 열 죽음).

 

Y10K 준수 프로그램은 우주의 예상 수명과 일치하는 사람들에게 지원 날짜 범위를 제한하도록 선택할 수 있습니다.Y10K 호환 시스템은 과거 10 년 2 년에서 미래의 10 ** 20 년으로 Y10K 날짜를 수락해야합니다.Y10K 호환 시스템은 과거와 미래에 최소 10 ** 29 년 동안 날짜를 수락해야합니다.

Visual Studio는 Visual Studio 2005에서 time_t의 64비트 표현으로 이동했습니다(이전 버전과의 호환성을 위해 _time32_t는 그대로 유지).

항상 time_t를 기준으로 코드를 작성하고 크기에 대해 아무 것도 가정하지 않는 한 sysrqb가 지적한 대로 문제는 컴파일러에 의해 해결될 것입니다.

내 생각엔 버그를 그대로 놔둬야 할 것 같아.그러면 2036년경에 우리는 모든 것을 테스트하기 위해 많은 돈을 받고 컨설팅 회사를 판매하기 시작할 수 있습니다.결국 우리가 1999-2000년 롤오버를 성공적으로 관리한 방법은 이것이 아니었습니다.

그냥 장난이야!

나는 1999년 런던의 한 은행에 앉아 있었는데 컨설턴트가 Y2K 커피 머신 테스트를 시작하는 것을 보고 매우 놀랐습니다.그 실패로부터 우리가 배운 것이 있다면 대부분의 소프트웨어는 제대로 작동하고 나머지 대부분은 장애가 발생하더라도 붕괴를 일으키지 않으며 필요하다면 이벤트 이후에 고칠 수 있다는 것입니다.따라서 나는 그 때가 훨씬 가까워질 때까지 특별한 예방 조치를 취하지 않을 것입니다.

내 나이를 감안할 때 연금에 많은 돈을 지불하고 모든 부서에 대한 비용을 지불해야 한다고 생각하므로 다른 사람이 소프트웨어를 맞춰야 할 것입니다!

죄송합니다. 현재 작성하는 소프트웨어의 "순 현재 가치"를 생각해 보면 2038년에 소프트웨어가 수행하는 작업에는 아무런 영향이 없습니다.몇 년 이상의 "투자 수익"은 어떤 소프트웨어 프로젝트에서도 흔하지 않습니다. 따라서 너무 앞서 생각하는 것보다 소프트웨어를 더 빨리 배송함으로써 고용주에게 더 ​​많은 돈을 벌 수 있습니다.

유일한 일반적인 예외는 미래를 예측해야 하는 소프트웨어입니다. 2038년은 이미 모기지 견적 시스템에 문제가 됩니다.

문서를 잘 보관하고 시간 종속성에 대한 설명을 포함하세요.나는 많은 사람들이 이 전환이 얼마나 어려울지 생각하지 않았다고 생각합니다. 예를 들어 HTTP 쿠키는 해당 날짜에 중단될 것입니다.

2038년, 우리는 무엇을 준비해야 할까?

종말이 다가오고 있기 때문에 숨으십시오.

하지만 진지하게, 나는 컴파일러(또는 그것을 작성하는 사람들)가 이 문제를 처리할 수 있기를 바랍니다.그들은 거의 30년을 보냈습니다.시간이 충분하길 바랍니다.

Y10K 준비는 언제부터 시작하나요?하드웨어 제조업체/연구실에서 우리가 갖게 될 신기술로 전환하는 가장 쉬운 방법을 모색한 적이 있습니까?

저는 임베디드 분야에서 일하고 있으며 여기에 솔루션을 게시해야겠다고 생각했습니다.우리 시스템은 32비트이며, 현재 우리가 판매하는 제품의 보증 기간은 30년입니다. 즉, 2038년 버그가 발생하게 됩니다.향후 업그레이드는 해결책이 아니었습니다.

이 문제를 해결하기 위해 커널 날짜를 현재 날짜보다 28년 빠르게 설정했습니다.이는 무작위 오프셋이 아니며, 요일이 다시 일치하는 데 걸리는 시간은 정확히 28년입니다.예를 들어 제가 목요일에 이 글을 쓰고 있는데 다음 3월 7일이 목요일이 되는 날은 28년 만입니다.

또한 당사 시스템의 날짜와 상호 작용하는 모든 애플리케이션은 시스템 날짜(time_t)를 사용하여 이를 사용자 정의 time64_t로 변환하고 28년 오프셋을 올바른 날짜에 적용합니다.

우리는 이를 처리하기 위해 사용자 정의 라이브러리를 만들었습니다.우리가 사용하는 코드는 다음을 기반으로 합니다. https://github.com/android/platform_bionic

따라서 이 솔루션을 사용하면 쉽게 28년을 더 연장할 수 있습니다.

2038년까지 시간 라이브러리는 모두 64비트 정수를 사용해야 하므로 이는 실제로 그렇게 큰 문제는 아닙니다(완전히 유지 관리되지 않는 소프트웨어에서는).

COBOL 프로그램은 재미있을 수도 있습니다.

작동 단어는 "해야 한다"입니다.

미래 보장을 보장해야 한다면 자신만의 날짜/시간 클래스를 구성하여 사용할 수 있지만, 작성한 내용이 레거시 OS에서 사용될 것이라고 생각하는 경우에만 그렇게 할 것입니다.

라이센스 : CC-BY-SA ~와 함께 속성
제휴하지 않습니다 StackOverflow
scroll top