2038 년 1 월 19 일 3:14:08에 Linux 시계가 작동하지 않습니까?

나는 이것에 대해 조금 걱정하고 있습니다. 이것을 "2038 년 문제"라고합니다. 12.04 기준으로 Linux 커널 또는 Ubuntu가 아직 날짜를 처리 할 준비가 되셨습니까?

아니요, 실패하지 않습니다. 최악의 경우 프로그래머의 관점에서 예상대로 작동합니다. 1901-12-13 20:45:52로 재설정됩니다.

이런 상황이 발생할 때까지 현재 배포를 업데이트하지 않을 경우에 대비합니다. " 업데이트는 쉽습니다. 이러한 업데이트 중 하나에는 반드시 수정 사항이 포함됩니다. "와 같이 chocobai 는 말했습니다.

나는 그것이 2000 이전의 16 비트 머신에서 똑같은 문제 / 질문 이었다는 것을 기억하고 결국에는 아무런 문제가 없었습니다.

Wikipedia의 솔루션 :

64 비트 하드웨어에서 실행되도록 설계된 대부분의 운영 체제는 이미 부호있는 64 비트 time_t정수를 사용합니다. 부호있는 64 비트 값을 사용하면 우주의 예상 연령보다 20 배 이상 큰 새로운 랩 어라운드 날짜가 도입됩니다. 292,277,026,596. 날짜 계산 기능은 다음과 같은 사실에 의해 제한됩니다.tm_year연도 1900에서 시작하는 부호있는 32 비트 int 값을 사용합니다. 이는 연도를 최대 2,147,485,547 (2,147,483,647 + 1900)으로 제한합니다. 이렇게하면 프로그램 실행 문제가 해결되지만 이진 데이터 파일 내에 날짜 값을 저장하는 문제는 해결되지 않으며, 대부분은 엄격한 저장소 형식을 사용합니다. 호환성 계층에서 실행되는 32 비트 프로그램의 경우 문제를 해결하지 않으며 시간 값을 다른 유형의 변수에 잘못 저장하는 프로그램의 경우 문제를 해결할 수 없습니다 time_t.

64 비트에서 Ubuntu 13.04를 사용하고 호기심으로 수동으로 시간을 2038-01-19 03:13:00으로 변경했습니다. 03:14:08 이후 아무 일도 일어나지 않았습니다 :

따라서이 문제에 대해 걱정할 것이 없습니다.

추가 정보 :

• 2038 년 문제-Wikipedia .
• 종료 시간 (Unix)-Numberphile .

다음 Perl 스크립트를 사용하여 컴퓨터 시간이 충돌하는지 확인할 수 있습니다.

#!/usr/bin/perl
use POSIX;
$ENV{'TZ'} = "GMT";
for ($clock = 2147483641; $clock < 2147483651; $clock++) {
    print ctime($clock);
}

컴퓨터가 괜찮다면 다음과 같이 얻을 수 있습니다.

Tue Jan 19 03:14:01 2038
Tue Jan 19 03:14:02 2038
Tue Jan 19 03:14:03 2038
Tue Jan 19 03:14:04 2038
Tue Jan 19 03:14:05 2038
Tue Jan 19 03:14:06 2038
Tue Jan 19 03:14:07 2038       <-- Last second in 32-bit Unix systems
Tue Jan 19 03:14:08 2038
Tue Jan 19 03:14:09 2038
Tue Jan 19 03:14:10 2038

컴퓨터가 내 것과 같은 경우 다음과 같이 둘러 쌉니다.

Tue Jan 19 03:14:01 2038
Tue Jan 19 03:14:02 2038
Tue Jan 19 03:14:03 2038
Tue Jan 19 03:14:04 2038
Tue Jan 19 03:14:05 2038
Tue Jan 19 03:14:06 2038
Tue Jan 19 03:14:07 2038
Fri Dec 13 20:45:52 1901
Fri Dec 13 20:45:52 1901
Fri Dec 13 20:45:52 1901

또한 이것을 할 수 있습니다 :

Tue Jan 19 03:14:01 2038
Tue Jan 19 03:14:02 2038
Tue Jan 19 03:14:03 2038
Tue Jan 19 03:14:04 2038
Tue Jan 19 03:14:05 2038
Tue Jan 19 03:14:06 2038
Tue Jan 19 03:14:07 2038
Tue Jan 19 03:14:07 2038
Tue Jan 19 03:14:07 2038
Tue Jan 19 03:14:07 2038

나는 1996 년에 이것에 관한 짧은 논문을 쓰고 출판했다. 여기에는 그것을 보여주는 짧은 C 프로그램이 포함되어있다. 또한 NTP (Network Time Protocol)와 유사한 문제에 대해 David Mills와 이메일을 보냈습니다. 내 우분투 14.04 64 비트 랩톱에서 perl 코드는 한계를 나타내지 않았으므로 기본 64 비트 라이브러리가 수정되어야합니다.

그러나 오랜 테스트 코드를 실행하면 시간이 UNIX Epoch로 되돌아 간 것을 알 수 있습니다. 따라서 모든 것이 과거의 32 비트 코드와 잘 맞지는 않습니다.

나의 1996 년 논문, 유닉스 타임은 2038 년에 끝날 것입니다! 이 "UNIX Time"이라는 제목의 변형이 1998 년 "Y2K Millennium Computing을위한 2000 년 베스트 프랙티스"ISBN 0136465064에 출판되었습니다.

적어도 핵심 OS 인터페이스에 대해 이야기하고 있다면 64 비트 Linux가 준비되었습니다 (개별 응용 프로그램은 여전히 ​​망칠 수 있습니다). time_t는 일반적으로 64 비트 Linux에서 "long"및 "long"의 별칭으로 정의되며 64 비트입니다.

32 비트 Linux (및 64 비트 Linux의 32 비트 바이너리에 대한 호환성 계층)의 상황은 훨씬 덜 장미 빛입니다. 깨진 모든 기존 바이너리를 손상시키지 않고 그것을 고치는 것은 쉬운 일이 아닙니다. 전체 API는 time_t를 사용하며 많은 경우 데이터 구조의 일부로 임베드되므로 API를 복제해야 할뿐만 아니라 작업하는 데이터 구조도 동일해야합니다.

이전 버전과의 호환성이 어느 정도라도 새로운 64 비트 시간 인터페이스를 사용하려면 정확한 시간을 원하는 모든 바이너리를 다시 빌드해야합니다.

일부 작업이 수행되었지만 (예 : https://lwn.net/Articles/643234/ 및 http://www.sourceware.org/ml/libc-alpha/2015-10/msg00893.html 참조 ) 우리는 실패했습니다 여전히 완전한 솔루션에서 먼 길입니다. Y2K38에 안전한 범용 32 비트 배포판이 있는지는 확실하지 않습니다.