TZif(zoneinfo) 파일 검사기

사용법

1. 컴파일된 존 파일을 상자에 놓으세요. /usr/share/zoneinfo에서 복사하거나 docker cp로 컨테이너에서 꺼내거나 JDK에서 꺼낸 파일도 됩니다.
2. 요약을 먼저 보세요. 버전, 전이 개수, 그리고 미래가 나열되어 있는지(fat) POSIX 규칙에 맡겨졌는지(slim) 아니면 고정인지 알 수 있습니다.
3. 헤더의 두 열을 비교하세요. 슬림 파일은 거의 빈 32비트 블록 옆에 꽉 찬 64비트 블록이 보이는데, 이는 손상이 아니라 설계대로입니다.
4. 기준 시각과 다음 전이를 확인하면 이 파일이 오늘 어떤 오프셋을 주고 언제 바뀌는지 알 수 있습니다.
5. 슬림 파일이라면 POSIX 푸터 항목을 펼치세요. 마지막 전이 이후의 모든 날짜는 거기 있는 M·J·0 기준 규칙만으로 결정됩니다.

자주 묻는 질문

헤더 카운트가 왜 두 벌인가요?

버전 2 이상 파일이 실제로 데이터를 두 번 담기 때문입니다. 먼저 전이 시각이 32비트인 버전 1 블록이 통째로 들어가고, 그 뒤에 두 번째 헤더와 64비트 블록, 마지막으로 POSIX 푸터가 옵니다. 2004년 이전에 작성된 리더가 실패하지 않고 읽을 것을 남겨 두려는 구조이고, RFC 8536은 요즘 리더에게 두 번째 블록으로 건너뛰라고 말합니다. 그래서 카운트가 다를 수 있습니다. zic의 슬림 출력에서는 첫 블록이 타입 하나에 전이 0개로 줄고 진짜 데이터는 두 번째 블록에 들어갑니다. 어떤 도구가 이 존에는 이력이 없다고 말한다면 대개 레거시 블록을 잘못 읽고 있는 것이고, 아직 그렇게 동작하는 라이브러리가 있습니다.

fat 파일과 slim 파일은 무엇이 다른가요?

같은 존을 설명하지만 미래를 얼마나 적어 두는지가 다릅니다. fat 파일은 2037년까지 모든 전이를 나열해서 Europe/Berlin이라면 약 140개가 들어가고 올해 10월 변경도 표에서 바로 읽힙니다. slim 파일은 규칙으로 유도할 수 없는 마지막 전이에서 멈추고 그 뒤는 POSIX 푸터 문자열에 맡기므로 크기가 10분의 1이 되기도 합니다. 2020년부터 zic의 기본값은 slim이지만 배포판마다 다릅니다. 데비안과 우분투는 여전히 fat을 배포하고, 알파인을 비롯한 여러 컨테이너 베이스 이미지는 slim을 배포합니다. 푸터를 무시하는 리더는 fat 파일에서는 멀쩡하다가 slim 파일에서 내년을 조용히 틀립니다. 어떤 이미지에서만 재현되는 버그가 대개 이것입니다.

POSIX 푸터는 어떻게 읽고 M·J·숫자 형식은 무슨 뜻인가요?

푸터는 TZ 환경 변수에 넣는 문자열과 같은 형식입니다. 표준시 약어, 표준시 오프셋, 그리고 선택적으로 서머타임 약어와 오프셋, 둘 사이를 오가는 규칙 두 개로 이루어집니다. 오프셋은 POSIX 방식이라 그리니치 서쪽이 양수입니다. 그래서 CET-1이 UTC+01:00을 뜻하고 이 도구는 부호를 되돌려 보여 줍니다. 규칙은 세 가지 형식입니다. Mm.w.d는 월·주·요일이고 주가 5면 마지막 주이므로 M3.5.0은 3월 마지막 일요일입니다. Jn은 1부터 세는 연중 날짜이면서 2월 29일을 절대 세지 않으므로 J60은 언제나 3월 1일입니다. 숫자만 쓰는 형식은 0부터 세고 2월 29일을 포함하므로 59는 평년에 3월 1일, 윤년에 2월 29일입니다. 마지막 형식은 드물고 구현마다 해석이 갈립니다. 파이썬 zoneinfo는 glibc보다 하루 늦게 계산합니다.

Etc/GMT+5 파일의 오프셋이 왜 -05:00으로 나오나요?

Etc 계열 이름은 POSIX 부호 규약을 따르는데, 이 규약은 다른 모든 곳과 부호가 반대입니다. TZ 문자열에서는 양수가 그리니치 서쪽을 뜻합니다. 그래서 Etc/GMT+5는 UTC보다 다섯 시간 늦은 존이고, ISO 8601과 거의 모든 화면에서는 이를 -05:00으로 씁니다. 반대로 Etc/GMT-5가 다섯 시간 빠른 쪽입니다. tz 데이터베이스는 POSIX가 그 동작을 요구하기 때문에 이 이름들을 유지하면서도 함정이라고 경고합니다. 이 도구는 오프셋을 ISO 방식으로 표시하므로, 이름은 +5인데 오프셋이 -05:00인 것은 모순도 버그도 아니고 이름 규약이 드러난 것입니다.

윤초 레코드는 무엇이고 right/ 파일의 전이 시각은 왜 이상해 보이나요?

tz 데이터베이스는 두 가지로 컴파일할 수 있습니다. 타임스탬프가 윤초를 뺀 초의 개수인 보통의 posix/ 트리와, 1972년 이후의 윤초를 레코드로 담고 타임스탬프가 실제 경과 초를 세는 right/ 트리입니다. 대부분의 시스템은 앞쪽만 배포하므로 여기에 윤초 표가 보인다면 right/ 파일이거나 누군가 zic -L로 컴파일한 파일입니다. 그런 파일에서는 전이가 누적 보정만큼 밀립니다. 01:00:00이어야 할 전환이 01:00:27로 보이는데, 1972년 이후 윤초 27개가 삽입되었기 때문이고 보정 열도 같은 27까지 올라갑니다. posix/ 시각을 기대하는 시스템에 right/ 파일을 섞으면 정확히 27초가 어긋납니다.

이 파일이 어느 존인지, 혹은 손상되었는지 알 수 있나요?

둘 다 알 수 없고, 두 한계 모두 형식 자체의 성질입니다. TZif 파일에는 이름이 없습니다. 존의 정체는 오로지 데이터베이스 안의 경로에서 오고, 그래서 Asia/Istanbul 같은 링크는 Europe/Istanbul의 바이트까지 같은 사본이거나 심볼릭 링크라 내용으로는 구분되지 않습니다. 할 수 있는 최선은 약어, 오프셋, 전이 날짜라는 지문으로 존을 알아보는 것이고 여기 표들이 그 용도입니다. 형식 어디에도 체크섬이 없으므로 전이 표의 바이트 하나가 뒤집혀도 파일이 무효가 되지 않고 전이 시각이 조용히 옮겨지거나 다른 타입을 가리킬 뿐입니다. 길이가 카운트와 맞지 않는 경우만 탐지할 수 있고, 이 도구는 그것을 잘린 파일로 거부합니다.

관련 도구