IANA 시간대 데이터베이스(tz): 정의와 중요성

게시일: 9:00 AM , 작성자 시간.com 편집팀

IANA 시간대 데이터베이스(tz/tzdata)의 정의, America/New_York 같은 영역 명명법, 오프셋만으로 부족한 이유, 그리고 의존하는 주체들.

시간대 경계와 America/New_York, Europe/London, Asia/Kolkata 같은 IANA 영역 식별자가 표시된 세계 지도

IANA 시간대 데이터베이스의 실제 정체

소프트웨어에서 날짜와 시간을 다뤄본 적이 있다면, 여러분은 인지하지 못했을지라도 IANA 시간대 데이터베이스에 의존해 왔습니다. 이 데이터베이스는 tz database, tzdata, Olson database, 또는 zoneinfo 등 여러 이름으로 불리지만, 모두 같은 것을 가리킵니다. 즉, 전 세계 시간대와 이를 규율하는 규칙에 대한 협업 기반의 자유롭게 이용 가능한 목록입니다.

"목록"이라는 단어는 그 가치를 과소평가합니다. 이 데이터베이스는 단순히 어떤 지역이 어느 UTC 오프셋에 속하는지 나열하지 않습니다. 각 지역에 대한 완전한 역사를 기록합니다. 즉, 모든 오프셋 변경, 모든 일광 절약 시간 전환, 모든 전시 시간 조정, 그리고 예정된 모든 미래 규칙을 기록하며, 많은 경우 지역 평균시가 표준 시간대로 대체되기 시작한 19세기 중반까지 거슬러 올라갑니다. 여러분의 캘린더 앱이 1985년의 회의가 오늘의 같은 벽시계 시간과 한 시간 차이가 났음을 정확히 보여준다면, 그것이 바로 tz 데이터베이스가 작동하고 있는 것입니다.

이 데이터베이스는 텍스트 기반이며, 사람이 읽을 수 있고, 크기가 작습니다. 여러분의 컴퓨터에 탑재되어 제공되는 컴파일된 바이너리 형태는 불과 몇 메가바이트에 불과합니다. 그럼에도 불구하고, 이는 컴퓨팅에서 가장 조용히 복잡한 데이터셋 중 하나를 인코딩합니다.

간략한 역사

이 프로젝트는 1980년대 Arthur David Olson에 의해 시작되었습니다. 그는 첫 번째 버전을 조립하여 미국 국립보건원(NIH)의 서버에 호스팅했습니다. 수십 년 동안 이 프로젝트는 주로 공개 메일링 리스트를 통해 조정된 자원봉사 노력을 통해 유지 관리되었으며, 이것이 "Olson database"라는 오래된 이름이 여전히 문서에 등장하는 이유입니다.

Paul Eggert가 주요 편집자를 맡아 현재까지 프로젝트의 오랜 조정자 역할을 하고 있습니다. 그가 작성한 동봉된 theory.html 문서와 꼼꼼한 커밋 기록은 이 데이터베이스를 기술적 참고 자료일 뿐만 아니라 역사적 참고 자료로 만들었습니다.

2011년, 역사적 데이터를 둘러싼 짧지만 충격적인 법적 분쟁 이후, 운영 주체는 다른 핵심 인터넷 자원을 조정하는 동일한 기관인 인터넷 할당 번호 관리 기관(IANA)으로 이전되었습니다. IANA는 이제 공식 릴리스를 발행하며, 이것이 "IANA 시간대 데이터베이스"가 표준 이름이 된 이유입니다. 작업은 여전히 동일한 기여자 커뮤니티에 의해 수행됩니다. IANA는 제도적 근거지와 안정적인 배포 지점을 제공합니다.

명명 규칙: Area/Location

이 데이터베이스의 가장 독특한 특징 중 하나는 시간대 이름을 지정하는 방식입니다. 국가 이름이나 원시 오프셋 대신, 거의 항상 대표 도시에 기반한 Area/Location 형식을 사용합니다.

  • America/New_York
  • Europe/London
  • Asia/Kolkata
  • Australia/Sydney

"Area"는 일반적으로 대륙이나 대양(America, Europe, Asia, Pacific)이고, "Location"은 해당 시간대 내의 잘 알려진 도시입니다. 이 선택은 그 이면에 있는 이유를 이해하기 전까지는 기이해 보입니다.

도시는 안정적입니다. 정치적 경계와 오프셋은 그렇지 않습니다. 국가는 분열되고, 합병되고, 이름을 바꾸고, 시계를 변경합니다. 반면에 도시는 고정된 지리적 지점이며 연속적인 시간 기록 역사를 가지고 있습니다. America/New_York와 같이 "미국 동부 시간"이나 "UTC-5" 대신 시간대 이름을 지정하면, 여기에 첨부된 규칙이 발전하더라도 식별자가 유효하게 유지됩니다.

데이터베이스는 또한 정치적 분쟁을 피하고 단일 국가에 여러 시간대가 포함되는 경우가 많기 때문에(미국만 해도 12개 이상) 국가 이름을 의도적으로 피합니다. 각각의 별개 시간대에서 가장 인구가 많거나 역사적으로 중요한 도시를 중립적인 레이블로 선택합니다. 1970년 이후 두 지역이 동일한 시계 역사를 공유하면 하나의 시간대를 공유합니다. 역사가 달라지는 순간 별도의 항목을 얻습니다.

원시 오프셋만으로는 충분하지 않은 이유

초보자들이 흔히 저지르는 실수는 시간을 "UTC+5:30"으로 저장하고 끝내는 것입니다. 이것은 단일 시점에는 작동하지만, 미래 또는 반복 이벤트에 대해 추론해야 하는 순간 실패합니다. 오프셋은 장소의 정적 속성이 아니기 때문입니다. 오프셋은 정부가 지속적으로 그리고 종종 갑작스럽게 변경하는 규칙의 출력입니다.

데이터베이스가 흡수해야 했던 몇 가지 실제 사례를 고려해 보십시오.

  • 사모아는 2011년 12월 30일을 완전히 건너뛰었습니다. 사모아는 미국보다는 호주 및 뉴질랜드와 영업일을 맞추기 위해 날짜 변경선을 넘어 UTC-11에서 UTC+13으로 이동했습니다. 섬에 있는 사람들에게 그 금요일은 단순히 존재하지 않았습니다.
  • 국가들은 거의 통보 없이 일광 절약 시간제를 폐지, 채택 또는 일정을 변경합니다. 유럽 연합은 DST 폐지를 논의해 왔습니다. 여러 국가와 미국 주들은 최근 수십 년 동안 DST 규칙을 변경했습니다. 터키, 러시아 및 기타 국가들은 표준 오프셋을 완전히 변경했습니다.
  • DST 시작 및 종료 날짜가 변경됩니다. 미국은 2007년에 DST 경계를 변경했습니다. 이전 규칙을 하드코딩한 모든 시스템은 매년 몇 주 동안 조용히 잘못된 시간을 생성했습니다.

오프셋만 저장하면 "내년 11월 15일 산티아고의 현지 시간은 몇 시인가?"라는 질문에 답할 수 없습니다. 그 답은 아직 확정되지 않았을 수도 있는 규칙에 달려 있기 때문입니다. 시간대 식별자(America/Santiago)와 데이터베이스를 저장하면 소프트웨어가 과거나 미래의 모든 순간에 대해 올바른 오프셋을 계산하고 규칙이 변경될 때 자동으로 다시 계산할 수 있습니다.

이것이 핵심 가치 제안입니다. tz 데이터베이스는 장소의 정체성과 시계를 결정하는 끊임없이 변화하는 규칙을 분리합니다.

유지 관리 방법

유지 관리는 공개적으로 이루어집니다. 제안된 변경 사항(새로운 DST 규칙, 수정된 역사적 날짜, 정부 발표)은 공개 tz 메일링 리스트에서 논의되며, 기여자들은 증거로 관보, 뉴스 보도, 정부 법령을 인용합니다. 정확성은 중요하게 여겨집니다. 특히 역사적 데이터의 변경은 1차 출처에 대해 면밀히 조사됩니다.

릴리스는 연도와 문자로 버전이 지정됩니다: 2024a, 2024b, 2024c 등. 숫자는 연도이고, 문자는 해당 연도의 각 릴리스마다 증가합니다. 정부는 예측할 수 없는 일정에 따라 시계 변경을 발표하기 때문에 고정된 릴리스 주기는 없습니다. 조용한 해에는 두 번의 릴리스가 있을 수 있고, 정치적 변동이 많은 해에는 여러 번의 릴리스가 있을 수 있습니다. 시스템은 신속하게 업데이트해야 합니다. 오래된 데이터베이스는 규칙 변경이 발효된 후 잘못된 시간을 표시할 수 있기 때문입니다.

의존하는 대상

거의 모든 것입니다.

  • 운영 체제. Linux 배포판은 tzdata를 핵심 패키지로 제공합니다. macOS는 동일한 소스에서 시간대 데이터를 파생합니다. Windows는 레거시 이유로 자체 레지스트리 기반 시간대를 사용하지만 ICU 라이브러리 및 최신 API를 통해 IANA 시간대를 노출합니다.
  • 프로그래밍 언어. 사실상 모든 성숙한 날짜/시간 라이브러리는 tz 데이터베이스를 읽거나 번들로 제공합니다: Python의 zoneinfo, Java의 java.time, ICU 프로젝트, PostgreSQL, ICU를 통한 JavaScript 엔진, Ruby, PHP 등.
  • 애플리케이션. 캘린더, 예약 시스템, 금융 거래 플랫폼, 로그 분석 도구 및 스케줄링 서비스는 모두 이에 의존하며, 일반적으로 개발자가 이에 대해 생각하지 않습니다.

이러한 보편성이 바로 이 데이터베이스가 매우 중요한 이유입니다. 단일하고 공유되며 신중하게 유지 관리되는 진실 공급원은 한 시스템에서 예약된 회의가 운영 체제와 언어를 넘어 수십 년 전 또는 미래까지 다른 시스템에서 올바르게 표시됨을 의미합니다.

시간대 자체를 탐색하려면 IANA 시간대의 전체 목록을 살펴보거나 모든 시간대 디렉토리에서 시간대가 전 세계에 어떻게 매핑되는지 확인하십시오.

자주 묻는 질문

tz 데이터베이스는 tzdata, zoneinfo 및 Olson 데이터베이스와 동일합니까?

네. 이들은 모두 동일한 프로젝트를 가리키는 이름입니다. "tzdata"는 일반적으로 운영 체제용으로 패키징된 데이터 파일을, "zoneinfo"는 컴파일된 바이너리 디렉토리를, "Olson database"는 창립자 Arthur David Olson의 이름을 딴 오래된 역사적 이름입니다. 오늘날 공식 명칭은 IANA 시간대 데이터베이스입니다.

데이터베이스는 얼마나 자주 업데이트됩니까?

고정된 일정은 없습니다. 릴리스는 실제 세계의 사건(정부의 DST 규칙 또는 표준 오프셋 변경, 역사적 데이터 수정)에 의해 촉발됩니다. 어떤 해는 단일 릴리스가 있고, 다른 해는 여러 번 있을 수 있습니다. 각각은 2024a, 2024b와 같이 명명되며, 연도 내내 문자가 증가합니다.

America/New_York와 같은 도시 이름으로 시간대를 지정합니까?

도시는 지리적으로 고정되어 있고 연속적인 시간 기록 역사를 가지고 있는 반면, 국가, 국경 및 오프셋은 시간이 지남에 따라 변경됩니다. 대표 도시를 사용하면 각 시간대에 안정적이고 정치적으로 중립적인 식별자를 제공하여 기본 DST 또는 오프셋 규칙이 변경되더라도 유효하게 유지됩니다.

시간대 이름 대신 UTC 오프셋만 저장해도 됩니까?

단일 고정 시점에만 해당됩니다. 미래 또는 반복 이벤트의 경우 시간대 식별자를 저장해야 합니다. 오프셋은 일광 절약 시간 및 정부 결정에 따라 변경되기 때문입니다. 시간대 이름과 데이터베이스를 사용하면 소프트웨어가 모든 날짜에 대해 올바른 오프셋을 자동으로 계산할 수 있습니다.

현재 누가 프로젝트를 운영합니까?

2011년 운영을 인수한 IANA에 의해 발행되며, Paul Eggert가 공개 tz 메일링 리스트를 통해 작업하는 기여자 커뮤니티와 함께 조정합니다. 기술 작업은 여전히 협력적이고 자원봉사자 주도의 노력으로 남아 있습니다.

현재 시간 에서 이 도시들:

뉴욕 · 런던 · 도쿄 · 파리 · 홍콩 · 싱가포르 · 두바이 · 로스앤젤레스 · 상하이 · 베이징 · 시드니 · 뭄바이

현재 시간 (국가별):

🇺🇸 미국 | 🇨🇳 중국 | 🇮🇳 인도 | 🇬🇧 영국 | 🇩🇪 독일 | 🇯🇵 일본 | 🇫🇷 프랑스 | 🇨🇦 캐나다 | 🇦🇺 호주 | 🇧🇷 브라질 |

현재 시간 시간대:

UTC | GMT | CET | PST | MST | CST | EST | EET | IST | 중국 (CST) | JST | AEST | SAST | MSK | NZST |

무료 위젯 웹마스터용:

무료 아날로그 시계 위젯 | 무료 디지털 시계 위젯 | 무료 텍스트 시계 위젯 | 무료 단어 시계 위젯