인용하다왜 유닉스 시간은 1970-01-01부터 시작되나요?
언급된 답변 중 하나
Unix 시간은 2038년 1월 19일 03:14:07 GMT에 종료됩니다. 2038년 1월 19일 03:14:08 GMT에 여전히 32비트 Unix 시간을 사용하는 모든 컴퓨터에서 오버플로가 발생합니다. 이른바 '2038년 문제'다. 어떤 이들은 이것이 '2000년 문제'보다 더 큰 문제가 될 것이라고 믿는다. 2038년 문제에 대한 해결책은 Unix 시간을 64비트 정수로 저장하는 것입니다. 대부분의 64비트 운영 체제에서는 이미 이 작업을 시작했지만 많은 시스템은 2038년 이전에 업데이트되지 않을 수 있습니다.
- RHEL/CentOS 7.9를 무기한 실행하기로 결정한 경우 누군가가 64비트 시간 정수(서명된 또는 서명되지 않은)로 실행되는지 여부와 시간 문제가 언제 발생하는지에 대해 의견을 제시할 수 있습니까?
- 최신 Linux(예: RHEL/CentOS 9)의 시간 오버플로 문제에 대한 현재 솔루션은 무엇입니까? 했다그들을이 문제는 RHEL 5에서처럼 얼마 전에 해결되었습니까, 아니면 여전히 눈에 띄지 않는 문제입니까?
- 현재의 해결책이 무엇이든, 수학적으로는 너무 오래 지속될 수 밖에 없습니다. 그렇죠? 그렇다면 현재 일어나고 있는 최선의 해결 방법에 있어서 시간 오버플로는 언제 최종적으로 발생하며, 향후 발생 날짜는 언제입니까?
답변1
64비트 프로그램은 이미 2038년 이후의 타임스탬프를 처리할 수 있습니다. 이제 주요 관심사는 파일 시스템입니다. 128비트보다 큰 inode가 있는 ext4 파일 시스템(실행하여 "Inode 크기" 확인) 은 이 옵션을
dumpe2fs사용하면 커널 5.10 이상의 XFS 파일 시스템과 마찬가지로 작동합니다.bigtimeRHEL 8.3 이상 버전에서 지원됩니다. RHEL 7 파일 시스템 제한인 2038에 대해서는 잘 모르겠습니다.설치 중 경고 생성).현재 해결 방법은 가능할 때마다 64비트 타임스탬프를 사용하는 것입니다.
XFS는 현재 최대 2486개의 날짜를 지원합니다. Linux의 64비트 타임스탬프는 약 292,000,000,000년 전의 날짜를 나타낼 수 있습니다.