일부 코드가 2038년 이후에 실행되지 않는 이유에 대해 Stack Overflow에서 많은 질문을 보았지만 답변은 일반적으로 64비트 OS로 업그레이드하는 것이 좋습니다. 내 질문은 왜 이런 일이 발생합니까? 2000년 문제와 비슷한가? 다른 운영 체제를 사용하여 이 문제를 해결할 수 있습니까? 아니면 32비트 프로세서가 물리적으로 2038년 이후의 시간을 처리할 수 없습니까? 왜? (저는 Linux를 처음 사용하기 때문에 간단한 질문일 수도 있지만 실제로 답을 모르겠습니다.)
답변1
Unix 시스템의 시간은 에포크(1970년 1월 1일 00:00 UTC) 이후의 초 수로 추적됩니다. 2038년에는 이 시간이 32비트 정수의 저장 용량을 초과하게 됩니다. 이것이 64비트 커널이 문제를 해결하는 이유입니다. 인용하다위키피디아:
많은 플랫폼에서 특정 시점을 나타내는 Unix time_t 데이터 유형은 이전 섹션에서 설명한 대로 Unix 시간 숫자를 직접 인코딩하는 전통적으로 32비트(아래 참조)의 부호 있는 정수입니다. 32비트는 전체 범위가 약 136년이라는 의미입니다. 표현 가능한 가장 짧은 날짜는 1901년 12월 13일 금요일이고, 표현 가능한 가장 긴 날짜는 2038년 1월 19일 화요일입니다. UTC 2038-01-19 03:14:07 이 표현은 1초 안에 오버플로됩니다. 이 이정표에 대한 기대는 흥미롭기도 하고 두렵기도 합니다. 2038년 질문을 참조하세요.
일부 최신 운영 체제에서는 time_t가 64비트로 확장되었습니다. 이는 표현 가능한 시간을 양방향으로 약 2,930억년 연장하며, 이는 각 방향으로 현재 우주 나이의 20배 이상입니다.
추가 읽기여기.
답변2
내 질문은 왜 이런 일이 발생합니까?
32비트 부호 있는 정수의 최대값은 2147483647이므로 68년과 초가 조금 넘습니다. 따라서 1970년부터 초를 계산하는 부호 있는 32비트 정수 범위는 2038년에 종료됩니다.
2000년 문제와 비슷한가?
어떤 의미에서. Y2K는 소수점 이하 두 자리의 공간만 유지하고 32비트만 유지하는 것입니다.
다른 운영 체제를 사용하여 문제를 해결할 수 있나요?
틀림없이. 예를 들어, NTFS의 경우 Windows는 64비트 값을 사용하고 1601부터 시작하여 100ns 틱을 계산합니다. 이는 30828까지 충분합니다.
아니면 32비트 프로세서가 실제로 2038년 이후의 시간을 처리할 수 없습니까?
아니요, 32비트만으로는 충분하지 않습니다. 32비트 프로세서에서 실행되는 프로그램은 여러 32비트 단어와 일부 논리를 사용하여 더 큰 숫자를 처리할 수 있습니다. 이것이 암호화에 필요한 큰 숫자가 처리되는 방식입니다. (또한 이 32비트 시간 형식이 32비트 또는 16비트 시스템(또는 더 이상한 시스템)에서 처음 사용되었는지 궁금합니다.)
현 시점에서는 32비트 시스템의 많은/대부분의 기존 소프트웨어가 32비트 타임스탬프를 사용하고 OS 인터페이스가 이를 제공하므로 이는 "그냥" 호환성 문제입니다. 64비트 타임스탬프를 사용하는 새로운 시스템을 구축하는 것은 쉽지만, 이전 소프트웨어와 호환되는 방식으로 구축하는 것은 훨씬 더 어렵습니다. (그러나 제가 아는 한, 32비트 Linux에서 64비트 시간에 대한 지원은 이미 추가되었거나 개발 중입니다.)