- 들어가며 — 7월 8일, 아무도 릴리스 노트를 읽지 않는 인프라
- 올해의 세 릴리스 — 한눈에
- 캐나다 서부가 시계 돌리기를 멈췄다
- 밴쿠버의 새 약어는 MST다 — 약어를 고르는 일의 어려움
- tzdb가 일부러 "틀린" 전환 날짜를 실은 이유 — CLDR 48.1의 제약
- 모로코, 8년 만의 +00 복귀 — 그리고 2087년까지의 예측이 지워졌다
- 2026a의 조용한 기본값 변화들
- 당신의 스택은 언제 2026c를 받나 — 두 개의 데드라인
- 마치며
- 참고 자료
들어가며 — 7월 8일, 아무도 릴리스 노트를 읽지 않는 인프라
2026년 7월 8일, IANA 시간대 데이터베이스의 올해 세 번째 릴리스 tzdata 2026c가 나왔습니다. 이 데이터베이스는 지구상 모든 시간대의 UTC 오프셋, 전환 규칙, 그리고 과거 변경 이력을 담은 텍스트 파일 묶음이고, 여러분의 스택 어딘가에 반드시 들어 있습니다 — glibc가 읽는 /usr/share/zoneinfo, JDK가 들고 다니는 자체 사본, Go 표준 라이브러리에 임베드된 사본, 그리고 ICU를 거쳐 브라우저·Node·Android까지.
이 데이터가 갱신되는 이유는 늘 같습니다. 어느 정부가 시간에 관한 법을 바꿨기 때문입니다. 올해는 그 입력이 유난히 굵직했습니다 — 캐나다의 두 주(그리고 아마 곧 세 번째 준주)가 계절 시계 변경을 폐지했고, 모로코가 8년 만에 GMT로 돌아가기로 했습니다. 그 과정에서 tzdb가 CLDR의 제약 때문에 일부러 법적 발효일과 다른 전환 날짜를 싣는 보기 드문 일도 벌어졌습니다.
이 글은 올해 세 릴리스(2026a/2026b/2026c)가 실제로 바꾼 것을 1차 소스(NEWS 파일과 zone 데이터) 기준으로 따라가고, 가을에 있는 두 개의 데드라인 전에 무엇을 점검해야 하는지 정리합니다. 시간대·타임스탬프의 일반론은 타임스탬프와 시간대 편에서 이미 다뤘으니, 여기서는 2026년에 실제로 바뀐 것만 봅니다.
올해의 세 릴리스 — 한눈에
| 릴리스 | 날짜 | 핵심 변경 |
|---|---|---|
| 2026a | 2026-03-01 | 몰도바 과거 데이터 소급 수정, right(윤초 반영) 파일 기본 설치 제거, TZif 약어 공간 50→256바이트 |
| 2026b | 2026-04-22 | 브리티시컬럼비아 영구 -07, zic 오버플로 수정 |
| 2026c | 2026-07-08 | 앨버타 영구 -06, 모로코 9월 20일부로 영구 +00, zic 오버플로 추가 수정 |
tzdata는 정기 릴리스가 아니라 "필요할 때" 나옵니다. 최근 3년(2023~2025)은 각각 4회·2회·3회였고, 올해는 7월에 벌써 세 번째입니다. 그리고 NEWS 파일이 예고하듯 노스웨스트 준주 건으로 "곧 또 한 번의 릴리스가 필요할 가능성이 높은" 상태입니다.
캐나다 서부가 시계 돌리기를 멈췄다
브리티시컬럼비아(BC)가 먼저였습니다. BC 주정부 발표(2026AG0013)에 따르면 2026년 3월 8일의 봄 전환(spring forward)이 마지막 시계 변경이고, 이후 BC는 연중 -07에 머뭅니다. 법률 문구가 재미있는데, tzdb 주석에 인용된 Paul Eggert의 정리에 따르면 "3월 8일 02:00의 통상적인 PST→PDT 전환 후 21시간이 지난 다음 날(3월 9일 00:00)부터 새 표준시 Pacific Time이 시작"됩니다. 즉 시계 변경은 한 번인데 명칭 변경은 21시간 간격으로 두 번 일어나는 구조입니다.
앨버타가 뒤따랐습니다. 경위가 꽤 관료적으로 흥미롭습니다 — Bill 31(Red Tape Reduction Statutes Amendment Act, 2026)의 3절이 기존 Daylight Saving Time Act를 폐지하고 Official Time Act(Chapter O-5.7)로 대체하면서 UTC-6을 표준시로 못 박았고, 2026년 5월 14일 국왕 재가를 받은 뒤 6월 18일 Order in Council 204/2026으로 같은 날 발효됐습니다. 같은 날 나온 OiC 206/2026은 이 시간의 공식 명칭을 "Alberta Time"으로 정했는데, 이 규정에는 2031년 6월 30일 만료 조항이 붙어 있습니다 — 명칭의 유효성을 그때 재검토하겠다는 뜻입니다. tzdb 주석은 이 명칭 규정이 "시간 계산에도 TZDB 데이터에도 영향이 없다"고 건조하게 덧붙입니다.
앨버타의 연중 -06은 사실 낯선 시간이 아닙니다. 이웃 서스캐처원이 수십 년째 쓰는 바로 그 시간이고, tzdb의 America/Regina는 오래전부터 -6:00 - CST로 끝납니다. 앨버타가 그 대열에 합류한 셈입니다.
노스웨스트 준주(NWT)는 아직입니다. 준주 수상이 "앨버타가 하면 따라가겠다"고 밝혀 왔고 실제로 폐지를 발표했지만, 법적 절차가 끝나지 않아 2026c에는 데이터가 아니라 주석으로만 들어 있습니다. America/Inuvik의 zone 정의 아래에는 이런 주석이 달려 있습니다.
Zone America/Inuvik 0 - -00 1953 # Inuvik founded
-8:00 NT_YK P%sT 1979 Apr lastSun 2:00
-7:00 NT_YK M%sT 1980
-7:00 Canada M%sT
# Assuming Northwest Territories follows Alberta in abolishing seasonal time
# changes, replace the above line with something like:
# -7:00 Canada M%sT 2026 Nov 1 2:00
# -6:00 - CST
법이 통과되면 주석을 풀고 릴리스하겠다는, 데이터베이스에 미리 심어 둔 TODO입니다. 2026d가 예고된 이유입니다.
밴쿠버의 새 약어는 MST다 — 약어를 고르는 일의 어려움
BC의 새 표준시의 법적 명칭은 Pacific Time입니다. 자연스러운 약어는 PT인데, 여기서 문제가 생깁니다 — tzdb와 POSIX는 시간대 약어를 3자 이상 6자 이하의 영숫자(또는 부호)로 요구하고, PT는 한 글자가 모자랍니다. Eggert는 BC 정부에 약어를 문의했지만 답을 받지 못했다고 주석에 적어 두었습니다. 그래서 tzdb 주석에는 후보별 품평이 그대로 남아 있습니다.
| 후보 | tzdb 주석의 평가 |
|---|---|
| MST | 기존 소프트웨어·관행과 가장 호환. BC 일부 지역과 유콘이 이미 -07에 이 약어를 사용 |
| PDT | 거의 무난하지만, 실제로는 표준시인데 DST라는 오해를 유발 |
| PST | 직관적이지만 더 혼란스럽고, PST가 -08이라고 가정하는 소프트웨어를 깨뜨릴 가능성 |
| -07 | 그 자체로 정확하지만 이웃 지역과 나란히 놓으면 어색 |
| PacT | 직관적이지만 전례 없는 새 약어 |
결론은 MST였습니다. 그래서 2026c의 zone 정의는 이렇게 생겼습니다.
Zone America/Vancouver -8:12:28 - LMT 1884
-8:00 Vanc P%sT 1987
-8:00 Canada P%sT 2026 Mar 9
# Temporary hack; see above.
-8:00 1:00 PDT 2026 Nov 1 2:00
# End of temporary hack.
-7:00 - MST
Zone America/Edmonton -7:33:52 - LMT 1906 Sep
-7:00 Edm M%sT 1987
-7:00 Canada M%sT 2026 Jun 18
# Temporary hack; see above.
-7:00 1:00 MDT 2026 Nov 1 2:00
# End of temporary hack.
-6:00 - CST
밴쿠버가 MST, 에드먼턴이 CST가 됩니다. 여기서 얻을 실무 교훈은 하나입니다 — 시간대 약어는 식별자가 아닙니다. PST는 -08이고 MST는 산악 표준시라는 가정은 이제 캐나다 서해안에서 깨집니다. 약어를 파싱하거나 약어로 분기하는 코드가 있다면, 지금이 IANA zone ID(America/Vancouver)로 옮길 때입니다.
tzdb가 일부러 "틀린" 전환 날짜를 실은 이유 — CLDR 48.1의 제약
위 zone 정의에서 이상한 점을 눈치챘을 겁니다. BC의 법적 발효일은 3월 9일, 앨버타는 6월 18일인데, 데이터는 두 곳 모두 11월 1일 02:00에 전환하는 것으로 되어 있습니다. 주석에 "Temporary hack"이라고 적혀 있는 부분입니다.
이유는 tzdb 주석에 명시돼 있습니다. 법적 날짜대로 3월 9일부터 "-07 표준시"로 모델링하면, CLDR 48.1(2026-01-08)이 이 구간의 표시 이름을 "Pacific Standard Time"이라고 만들어 버립니다 — 오프셋은 -07인데 이름은 -08짜리 표준시로 표기되는, 사용자에게 그대로 노출되는 오류입니다. 그래서 tzdb는 3월 9일부터 11월 1일까지를 일단 기존처럼 PDT(서머타임)로 두었습니다. 주석의 표현을 옮기면, 이 구간은 실제로는 표준시이므로 엄밀히 말해 이 hack은 틀렸지만, UT 오프셋은 정확하고 CLDR의 제약을 우회한다는 것입니다. 11월이 되면 hack을 유지할 이유 자체가 없어지므로 그때 제거할 수 있으리라는 계획도 함께 적혀 있습니다.
앨버타 쪽 주석에는 한 겹이 더 있습니다 — 앨버타의 hack은 CLDR 48.2(2026-03-17) 이하에서도 필요한데, "마이너 CLDR 릴리스를 따라가는 플랫폼은 소수라서 두 hack의 실질 효과는 비슷하다"는 것입니다.
이 사건이 흥미로운 이유는 방향입니다. 데이터의 원천(tzdb)이 소비자(CLDR/ICU)의 릴리스 주기와 제약에 맞춰 데이터를 구부린 것이니까요. 실제로 표시 이름의 공급 사슬은 이렇게 흐릅니다 — tzdb가 오프셋과 전환을 정의하고, CLDR이 언어별 표시 이름을 붙이고, ICU가 그걸 라이브러리로 묶으면, 브라우저의 Intl API·Java·Android가 그 위에서 시간대 이름을 보여 줍니다. ICU 릴리스 노트 기준으로 ICU 78.2(2026-01-09)가 CLDR 48.1 + tzdata 2025c, ICU 78.3(2026-03-17)이 CLDR 48.2 + tzdata 2026a를 실었고, 10월로 예정된 ICU 79가 CLDR 49 + Unicode 18을 실을 계획입니다. 이 주기를 감안하면 "11월까지 임시로 구부린다"는 선택이 왜 나왔는지 이해가 갑니다.
물론 공짜는 아닙니다. hack이 살아 있는 동안 밴쿠버와 에드먼턴의 여름은 법적으로는 표준시인데 데이터상으로는 isdst=1입니다. tm_isdst 값으로 분기하는 코드, 약어(PDT/MDT)를 표시하는 UI는 그동안 법과 다른 값을 보게 됩니다. 그리고 11월 1일 02:00에는 오프셋이 바뀌지 않는 "유령 전환"이 하나 일어납니다 — PDT→MST, MDT→CST로 이름과 isdst만 바뀌는 전환입니다. 전환 이벤트를 세거나 오프셋 변화를 가정하는 코드라면 이런 전환이 존재할 수 있다는 것도 알아 둘 일입니다.
모로코, 8년 만의 +00 복귀 — 그리고 2087년까지의 예측이 지워졌다
모로코는 2018년 10월부터 상시 +01을 쓰되 라마단 기간에만 +00으로 내려가는, 매년 두 번의 전환을 반복해 왔습니다. 2026c에 따르면 이 체제가 끝납니다 — 정부가 2026년 6월 25일 칙령(Decree No. 2.26.530)으로 2018년 칙령을 폐지했고, 2026년 9월 20일 02:00부터 영구 +00, DST 없음으로 돌아갑니다. 서사하라(Africa/El_Aaiun)도 함께입니다. tzdb가 인용한 보도는 Morocco World News의 확정 기사와 관보(Bulletin Officiel 7521호)입니다.
Zone Africa/Casablanca -0:30:20 - LMT 1913 Oct 26
0:00 Morocco %z 1984 Mar 16
1:00 - %z 1986
0:00 Morocco %z 2018 Oct 28 3:00
1:00 Morocco %z 2026 Sep 20 2:00
0:00 - %z
그리고 이 변경에는 눈에 잘 안 띄는 대청소가 딸려 왔습니다. 라마단은 이슬람력을 따르므로 매년 그레고리력 날짜가 이동하는데, tzdb는 그동안 천문 계산으로 2087년까지의 라마단 전환을 미리 계산해 규칙으로 실어 왔습니다. 2026b의 africa 파일에는 Morocco 규칙이 183줄 있었는데, 2026c에서는 57줄입니다 — 2027년부터 2087년까지의 예측 규칙 126줄이 통째로 삭제됐습니다. 시간대 데이터베이스가 60년치 미래 예측을 품고 있었다는 사실 자체가, 이 데이터가 얼마나 특이한 물건인지 보여 줍니다.
이 예측 규칙의 잔재는 스테일 데이터의 증상도 기묘하게 만듭니다. 2026b 이하 데이터로 9월 20일을 넘긴 시스템은 카사블랑카를 +01로 계산해 1시간 빠르게 표시합니다. 그런데 삭제된 옛 규칙에는 "2027-02-07에 +00으로 내려갔다가 2027-03-14에 +01로 복귀"라는 라마단 예측이 있었으므로, 그 5주 동안은 우연히 다시 맞았다가 3월 중순부터 또 틀리게 됩니다. 스테일 tzdata의 버그는 이렇게 간헐적으로 나타날 수 있습니다.
2026a의 조용한 기본값 변화들
캐나다와 모로코가 헤드라인이라면, 3월의 2026a는 기본값을 바꾼 릴리스였습니다. NEWS 기준으로 엔지니어에게 의미 있는 것만 추리면:
- right(윤초 반영) TZif 파일이 기본 설치에서 빠졌습니다. 시스템 클록이 윤초를 세는 (POSIX 비준수) 환경을 위한 대체 파일 세트인데, 주요 배포판에서 거의 쓰이지 않아 기본에서 제외됐습니다. 옛 기본값은
make REDO=posix_right로 복원할 수 있고, 정말 윤초 카운트 클록이라면make REDO=right_only가 권장됩니다. 윤초 자체가 어디로 가고 있는지는 2026년에도 윤초는 없다 편을 참고하세요. - 컴파일 옵션 TZ_RUNTIME_LEAPS=0이 생겼습니다. 런타임 윤초 지원을 끄는 옵션으로, POSIX에는 부합하고 공격 표면과 비용을 줄이지만 RFC 9636(TZif 포맷 표준)의 윤초 기능은 포기합니다.
- TZif 약어 공간이 50바이트에서 256바이트로 늘었습니다. 일부 파일이 이미 40바이트를 쓰고 있었으니 여유가 얼마 없었던 셈입니다. 오래된 커스텀 TZif 파서가 있다면 50바이트 가정을 확인할 이유가 생겼습니다.
- 몰도바의 과거가 소급 수정됐습니다. 몰도바는 2022년부터 EU 방식(03:00 전진, 04:00 후퇴)으로 전환해 왔는데 데이터가 02:00/03:00으로 잘못 남아 있었습니다. 과거 타임스탬프의 지역 시각 해석이 바뀌는 종류의 수정입니다 — tzdata 갱신이 미래만 바꾸는 게 아니라는 좋은 예입니다.
- 2019b부터 obsolete였던 posixrules 메커니즘이 완전히 제거됐습니다.
그리고 올해 세 릴리스를 관통하는 흐름이 하나 있는데, zic(존 컴파일러)의 하드닝입니다. 악의적 입력에 대한 정수·버퍼 오버플로 수정이 2026a/b/c에 걸쳐 계속 들어갔습니다. NEWS에 실린 재현 입력들은 Zone Ouch 0 - LMT 9223372036854775807 같은, 명백히 퍼징에서 나온 모양새입니다. 시간대 소스 파일을 신뢰 경계 밖에서 받아 zic으로 컴파일하는 시스템은 드물겠지만, tzcode도 공급망의 일부라는 점을 상기시켜 줍니다. 반대 방향의 결정도 있었습니다 — 2025c에서 강화했던 "비특권 프로세스의 TZif 경로 제한(정규 파일 강제, .. 경로 거부)"은 FreeBSD에서 안착하지 못해 2026c에서 되돌렸습니다. 보안 강화도 생태계가 받아들여야 유지된다는, 인프라 유지보수의 현실적인 단면입니다.
당신의 스택은 언제 2026c를 받나 — 두 개의 데드라인
릴리스가 나왔다고 끝이 아닙니다. 실제 전파 속도를 확인해 봤습니다(2026-07-17 기준, 각 프로젝트의 커밋·패키지 이력에서 직접 확인한 것만 적습니다).
| 경로 | 상태 |
|---|---|
| Go (golang/go lib/time) | 2026c를 릴리스 다음 날인 7월 9일에 병합 |
| Debian (tzdata 패키지) | 2026c-1 패키징 완료 |
| Fedora | 최근 stable 업데이트는 2026b-1 (5월 20일) |
| OpenJDK 메인라인 | 2026b까지 병합(4월 27일, JDK-8383175). 2026c는 이 글 시점 미병합 |
| ICU | 최신 유지보수판 78.3(3월 17일)이 tzdata 2026a 동봉 |
패턴이 보입니다. 배포판과 Go는 며칠 단위로 따라오고, JDK는 메인라인 병합 후 분기별 업데이트 릴리스를 타야 실제 JVM에 도달하며, ICU를 통해 시간대 데이터를 받는 플랫폼(브라우저, 일부 임베디드)은 ICU 릴리스 주기에 묶입니다. 여기에 컨테이너 베이스 이미지의 빌드 시점, JVM의 자체 tzdata 사본, pip의 tzdata 패키지처럼 런타임별 사본이 겹치면 — 같은 서버에서 프로세스마다 다른 시간대 데이터를 보는 일은 전혀 드물지 않습니다.
이번 릴리스 기준으로 달력에 적어둘 데드라인은 둘입니다.
- 2026-09-20 02:00 — 모로코·서사하라. 이전에 갱신 안 된 시스템은 이후 +01로 계산해 1시간 빠릅니다.
- 2026-11-01 02:00 — BC·앨버타. 스테일 데이터는 존재하지 않는 가을 전환(fall back)을 실행해, 밴쿠버를 -08로, 에드먼턴을 -07로 떨어뜨립니다. 이후 1시간 느립니다. NWT 입법이 끝나면 2026d와 함께 세 번째 항목이 추가될 수 있습니다.
내 시스템이 어느 쪽인지는 zdump로 바로 확인할 수 있습니다.
# 2026c가 적용됐다면: 9월 20일 +01 -> +00 전환이 보인다
zdump -v Africa/Casablanca | grep 2026
# 2026c가 적용됐다면: 11월 1일 전환에서 gmtoff가 -21600으로 유지된다 (MDT -> CST)
# 스테일 데이터라면: gmtoff가 -21600 -> -25200으로 떨어진다 (MDT -> MST)
zdump -v America/Edmonton | grep 2026
반대로, 이번엔 신경 쓰지 않아도 되는 경우도 분명히 있습니다. 한국 사용자만 상대하는 서비스라면 KST는 이번 릴리스와 무관하고, 과거 타임스탬프를 UTC로 저장·연산만 하는 백엔드는 오프셋 변경 자체로는 깨지지 않습니다. 위험한 것은 세 가지입니다 — 해당 지역의 미래 지역 시각 스케줄(9월 20일 이후의 "카사블랑카 09:00 회의"를 스테일 데이터로 UTC 변환해 저장하면 1시간 어긋난 순간에 발화합니다), 사용자에게 보여 주는 지역 시각 표시, 그리고 isdst나 약어에 의존하는 로직입니다.
마치며
tzdb는 "정치가 입력이고 데이터가 출력"인 특이한 인프라입니다. 올해의 입력은 캐나다 두 주의 법률과 모로코의 칙령이었고, 출력은 세 번(곧 네 번)의 릴리스, 그리고 CLDR 생태계를 위해 11월까지 유지되는 자발적인 "틀린 날짜" 하나였습니다. 요약하면:
- BC(3월 9일)와 앨버타(6월 18일)는 법적으로 이미 영구 시간이지만, tzdb에는 CLDR 48.x 우회를 위해 11월 1일 전환으로 실려 있고, 오프셋은 내내 정확합니다.
- 모로코·서사하라는 9월 20일 02:00부터 영구 +00입니다. 그 전에 tzdata 2026c가 함대 전체에 깔려 있어야 합니다.
- 시간대 약어(PST=-08 같은 가정)와 tm_isdst에 의존하는 코드는 이번 사이클에서 실제로 깨집니다. zone ID와 오프셋으로 계산하고, 약어는 표시용으로만 쓰세요.
아무도 릴리스 노트를 읽지 않는 인프라일수록, 한 시간이 사라진 뒤에야 존재가 드러납니다. zdump 한 줄이면 미리 알 수 있습니다.
참고 자료
- IANA Time Zone Database — 공식 페이지 (2026c, 2026-07-08)
- tz NEWS 파일 — 2026a/2026b/2026c 릴리스 노트 원문
- northamerica 소스 파일(2026c) — BC·앨버타·NWT zone 정의와 주석
- africa 소스 파일(2026c) — 모로코·서사하라 zone 정의
- tz-announce 메일링 리스트 아카이브
- BC 주정부 발표 — Adopting permanent daylight saving time (2026AG0013)
- Morocco World News — Morocco to Restore GMT on September 20 (tzdb 인용 출처)
- ICU 릴리스 — 78.2(CLDR 48.1)·78.3(CLDR 48.2) 노트
- OpenJDK — tzdata VERSION 갱신 커밋 이력 (JDK-8383175 등)
- Go — lib/time 갱신 커밋 이력 (2026c: 7월 9일)
- Debian tzdata 패키지 트래커
- 타임스탬프와 시간대 — 시간대 처리 일반론 (관련 글)
- 2026년에도 윤초는 없다 — 윤초와 UTC의 미래 (관련 글)
현재 단락 (1/93)
2026년 7월 8일, [IANA 시간대 데이터베이스](https://www.iana.org/time-zones)의 올해 세 번째 릴리스 tzdata 2026c가 나왔습니다. 이 ...