1641 년에 파일을 어떻게 '만들'수 있었습니까?

몇 년 전에 파일 서버에서이 파일을 발견했습니다.

그리고 1641 년에 파일이 생성되었다고 어떻게 말할 수 있습니까? 내가 아는 한, PC의 시간은 1970 년 1 월 1 일 이후의 초 수로 정의됩니다. 해당 인덱스가 고장 나면 1969 년 12 월 31 일 (색인은 -1이라고 표시됨)을 얻을 수 있지만 미합중국의 창립 이전의 것으로 보이는 임의의 날짜.

그렇다면 1641 년에 파일의 날짜를 어떻게 지정할 수 있습니까?

추신 : 날짜는 프랑스어로되어 있습니다. 페 비에르는 2 월입니다.

1600 년대의 데이트가 가능한 이유는 무엇입니까?

Windows는 Unix 시스템처럼 파일 수정 타임 스탬프를 저장하지 않습니다 . Windows Dev Center (강조 광산) 에 따르면 :

파일 시간은 1601 년 1 월 1 일 오전 12시 (UTC) 협정 세계시 (UTC) 이후 경과 한 100 나노초 간격 의 수를 나타내는 64 비트 값입니다 . 시스템은 응용 프로그램이 파일을 작성, 액세스 및 쓸 때 파일 시간을 기록합니다.

여기에 잘못된 값을 설정하면 1600 년대의 날짜를 쉽게 얻을 수 있습니다.

물론 또 다른 중요한 질문은이 값이 어떻게 설정 되었는가입니다. 실제 날짜는 무엇입니까? 파일 시스템 드라이버에서 계산 오류 일 수 있었기 때문에 결코 찾을 수 없을 것이라고 생각합니다. 또 다른 대답 은 날짜가 실제로 Windows 타임 스탬프로 해석되는 Unix 타임 스탬프 라고 가정 하지만 실제로는 다른 간격 (초 대 나노 초)으로 계산됩니다.

이것이 2038 년 문제와 어떤 관련이 있습니까?

64 비트 데이터 유형을 사용한다는 것은 Windows (일반적으로)가 2038 년의 영향을받지 않음을 의미합니다. Unix는 처음에 32 비트 정수를 사용했기 때문에 Windows의 64 비트 정수보다 빨리 오버플로되므로 기존 Unix 시스템의 문제 있다. (이것은 Unix가 초 단위로 작동하고 Windows가 마이크로 / 나노초 단위로 작동 함에도 불구합니다.)

물론 이전 버전의 Visual Studio로 컴파일 된 32 비트 프로그램을 사용하는 경우 에도 Windows 는 여전히 영향을받습니다 .

최신 Unix 운영 체제 는 이미 데이터 유형을 64 비트로 확장 하여 문제를 방지했습니다. (실제로 Unix 타임 스탬프는 몇 초 만에 작동하기 때문에 새로운 랩 어라운드 날짜는 지금부터 2,920 억 년이 될 것입니다.)

설정할 수있는 최대 날짜는 얼마입니까?

궁금한 점은 다음과 같이 계산하는 방법입니다.

• 64 비트 정수의 가능한 값의 수 있는 2 ⁶³ 1 = 9223372036854775807 -이 .
• 각 틱은 100 나노초 (0.1 µs 또는 0.0000001 s)를 나타냅니다.
• 최대 시간 범위는 9223372036854775807 ⨉ 0.0000001 s 이므로 수십억 초입니다.
• 1 시간은 3600 초, 하루는 86400 초, 1 년은 365 일이므로 1 년에 86400 ⨉ 365 초 = 31536000 초 입니다. 물론 이것은 평균적인 윤년, 윤초 또는 미래의 종말 이후의 정권이 나머지 지구인들에게 지시 할 수있는 달력의 변화를 무시한 것입니다.
• 9223372036854775807 ⨉ 0.0000001 s / 31536000 s ≈ 29247 년
• @corsiKa윤년을 빼는 방법을 설명합니다 : 29247/365/4 ≈ 20
• 따라서 최대 연도는 1601 + 29247 – 20 = 30828 입니다.

일부 사람들은 실제로 이것을 설정하려고 시도 했으며 같은 해를 생각해 냈습니다.

추측에 대해 너무 나쁘지 않다면 설명을하겠습니다. 그리고 "누군가가 말도 안되는 값으로 설정했다"는 의미는 아닙니다.

유닉스 시간은 일반적으로 1970 년 이후의 시간 (초)을 사용합니다. 반면에 Windows는 시작 연도로 1601을 사용합니다. 따라서 문제가 두 번의 잘못된 변환이라고 가정하면 (그리고 큰 가정입니다!), 표현되어야 할 날짜가 실제로 2011 년 언젠가 (1970 + 41)라고 잘못 상상할 수 있습니다. ~ 1640 (1601 + 41) . 편집 : 실제로, 나는 Windows 시작 연도에 실수를했다. 실제 생성 시간이 2010 년이거나 다른 오류가있을 수 있습니다 (소프트웨어에서 D1 오류는 매우 일반적입니다).

올해는 문제의 파일과 관련된 추적 날짜 중 하나가 될 것이므로 상당히 그럴듯한 설명이라고 생각합니다. :)

다른 사람들이 작성한 것처럼 Windows 시대는 1601-01-01 00:00 입니다.

해당 에포크와 표시되는 파일 시간 사이의 시간 (초) 은 1.266.705.294 입니다.
유닉스 시대에 이것을 추가하면, 우리 는 토요일, 2010-02-20 23:34:54 CEST에 도착 합니다. 이것은 마지막 액세스 날짜 약 1 년 전이므로 다소 타당합니다. 따라서 잘못된 시대에 대해 해석 된 유닉스 타임 스탬프 일 수 있습니다.

이러한 유형의 질문에 대해 평소와 같이 Raymond Chen의 블로그는 "Win32 시대가 왜 1601 년 1 월 1 일입니까?" 2009 년 3 월 6 일 :

이 FILETIME구조는 1601 년 1 월 1 일 이후로 100 나노초 간격으로 시간을 기록합니다. 그 날짜가 선택된 이유는 무엇입니까?

Gregorian 달력은 400 년 주기로 작동하며 1601은 Windows NT를 설계 할 당시 활성화 된주기의 첫해입니다. 다시 말해, 수학이 멋지게 나오도록 선택되었습니다.

실제로 Dave Cutler의 이메일에서이를 확인했습니다.