Co je databáze časových pásem IANA (a proč na ní záleží)

Když váš notebook v neděli ráno tiše posune čas o hodinu zpět, nebo když kalendářová pozvánka od kolegy ze São Paula dorazí přesně v okamžiku, který jste očekávali, odvedla práci tatáž neviditelná věc: volně udržovaná datová sada, kterou téměř každý operační systém, programovací jazyk a webová služba považuje za autoritu v otázce občanského času. Je to databáze časových pásem IANA — označovaná také jako databáze tz, tzdata nebo historicky Olsonova databáze, podle Arthura Davida Olsona, který ji začal udržovat v 80. letech.

Časová pásma působí jako zeměpis, ale jsou to politika. Vláda se může rozhodnout ukončit letní čas dříve, posunout svůj standardní posun nebo zcela přeskočit jeden den — někdy jen s pár týdny předstihu. Databáze tz je sdílený soubor pravidel, který tyto změny pohlcuje, takže otázka „kolik je v Londýně, když je v New Yorku 15:00?" má všude jednu konzistentní odpověď. Tento článek vysvětluje, co databáze ve skutečnosti obsahuje, jak se aktualizace dostane od vládního výnosu až do vašeho telefonu a proč je lákavá zkratka v podobě uložení pevného posunu jako „UTC+1" chybou, která jen čeká, až se projeví.

Co databáze ve skutečnosti je

Databáze tz je sada prostých textových souborů popisujících pravidla pro místní čas po celém světě — jak nyní, tak tak daleko do minulosti, kam záznamy rozumně sahají. Nespouštíte ji; software ji čte. Stáhnout si ji může kdokoli a data nenesou žádná licenční omezení, což je jeden z důvodů, proč skončila úplně všude.

Každý region je identifikován názvem pásma ve tvaru `Oblast/Lokalita`: `America/New_York`, `Europe/London`, `Asia/Kolkata`, `Australia/Lord_Howe`. Lokalita je obvykle reprezentativní město, nikoli země, a to je záměrné. Jediná země může pokrývat několik sad pravidel a názvy měst jsou v průběhu desetiletí mnohem stabilnější než hranice nebo názvy zemí. Databáze definuje několik stovek těchto pásem.

Pro každé pásmo data zaznamenávají:

• Základní posun vůči UTC — například `America/New_York` je v zimě UTC−5 (EST).
• Platná pravidla letního času, včetně přesného okamžiku, kdy každý rok začíná a končí.
• Historické přechody — každou minulou změnu posunu nebo pravidla DST daného pásma.
• Zkratky, které platily v jednotlivých obdobích, jako EST, EDT, CET nebo IST.

Právě tento historický rozměr odlišuje tzdata od pouhé tabulky posunů. Databáze neví jen to, že New York je dnes UTC−5. Ví, že Spojené státy od roku 2007 posunuly datum začátku letního času na dřívější termín, a aplikuje správné pravidlo pro libovolné datum, na které se zeptáte. Proto vám dobře postavený převodník dokáže říct posun pro datum v roce 1995 stejně s jistotou jako pro příští úterý.

Pásma, odkazy a matoucí položky „Etc"

Databáze také definuje odkazy (links) — aliasy, které směrují jeden název na jiný, aby přejmenování nerozbila stávající systémy. Když se indické pásmo ustálilo na `Asia/Kolkata`, starší `Asia/Calcutta` bylo zachováno jako odkaz na něj. Oba se stále převádějí na UTC+5:30.

Existují také pásma `Etc/` pro pevné posuny, včetně `Etc/UTC` a proslule obráceného `Etc/GMT+5`. To je UTC−5, nikoli UTC+5: názvy `Etc/GMT±` převracejí znaménko podle staré konvence POSIX. Tato pásma s pevným posunem existují pro specifické technické potřeby. Pro jakékoli místo, kde žijí skuteční lidé, chcete zeměpisné pásmo — protože jen zeměpisné pásmo ví o letním času a budoucích změnách pravidel. Další část vysvětluje, proč na tom záleží.

Proč se pravidla časových pásem mění tak často

Lidé předpokládají, že časová pásma jsou věc daná. Nejsou. Databáze tz se v běžném roce aktualizuje několikrát, někdy i víckrát. Vydání jsou verzována podle roku a písmene — `2023a`, `2023b`, `2024a` — a každé sdružuje veškeré změny pravidel a opravy, které se nahromadily od předchozího.

Změny pocházejí z hrstky opakujících se zdrojů:

• Vlády upravující politiku DST. Země začne dodržovat letní čas, přestane jej dodržovat nebo posune data přechodu. Evropská unie už léta diskutuje o zrušení sezonní změny času a několik amerických států přijalo zákony usilující o trvalý letní čas, které čekají na federální schválení.
• Přímé změny posunu. Občas některé území přejme zcela jiný standardní čas. Klasický případ: na konci roku 2011 Samoa úplně přeskočila 30. prosince, čímž se přesunula na druhou stranu mezinárodní datové hranice, aby svůj pracovní týden sladila s Austrálií a Novým Zélandem místo se západním pobřežím USA.
• Oznámení na poslední chvíli. To je ta těžká část. Vláda někdy oznámí změnu týdny — nebo dny — před jejím nabytím účinnosti. Správci a navazující dodavatelé pak závodí, aby aktualizaci vydali a distribuovali dřív, než to datum nastane.
• Historické opravy. Badatelé objeví staré zákony, novinové archivy nebo železniční jízdní řády, které upřesní, jaký posun pásmo *mělo* před desetiletími, a tyto opravy se rovněž zapracují.

Strohý závěr: pravidlo daného místa je známé jen do dalšího vládního rozhodnutí. Jakýkoli systém, který předpokládá, že dnešní pravidla jsou trvalá, se nakonec bude mýlit.

Jak se aktualizace dostane do vašeho telefonu

Databázi udržuje komunita dobrovolníků koordinujících se na veřejné e-mailové konferenci, přičemž IANA (Internet Assigned Numbers Authority) slouží jako oficiální domov a distribuční bod. Změna obvykle putuje takto:

1. Někdo ji nahlásí v konferenci tz, obvykle s odkazem na vládní věstník, oficiální oznámení nebo výzkum z primárních zdrojů. 2. Správci ji ověří a prodiskutují, poté úpravu zapíší do příslušného datového souboru. 3. IANA publikuje nové vydání s verzovým označením, například `2024a`. 4. Navazující konzumenti je zpracují — linuxové distribuce, macOS, běhová prostředí jazyků a hlavní platformy. (Windows si udržují vlastní formát časových pásem a mapují jej na názvy IANA.) 5. Vaše zařízení je převezme prostřednictvím aktualizace OS, aktualizace aplikace nebo, na serverech, balíčku jako `tzdata`.

Právě tento řetězec je také místem, kde se rodí reálné chyby. Databáze může být zcela aktuální, zatímco konkrétní zařízení nikoli. Notebook, který aktualizaci minul, dál aplikuje staré pravidlo a v den přechodu jdou hodiny špatně. Mezera mezi „pravidlo se změnilo" a „každé zařízení o tom ví" je tím největším jednotlivým zdrojem chyb časových pásem, na které ve skutečnosti narazíte.

Proč pevně zakódované posuny zastarají

Tady je ta chyba, jejímuž zabránění celý systém slouží. Vývojář se rozhodne uložit časové pásmo uživatele jako pouhé číslo — `+1` — protože to vypadá efektivně. Je to rozbité hned třemi způsoby naráz.

• Ignoruje to DST. `Europe/Paris` je v zimě UTC+1 a v létě UTC+2. Uložené `+1` je správné jen po část roku a každé jaro a podzim se výpočet odchýlí o hodinu.
• Nedokáže to reprezentovat samotný přechod. V ráno, kdy se hodiny posunou vpřed, jedna místní hodina neexistuje; v ráno, kdy se posunou zpět, jedna místní hodina nastane dvakrát. Holý posun nemá jak říct „02:30 nastalo dvakrát". Pojmenované pásmo, aplikované správnou logikou data, to umí.
• Zmrazuje to pravidlo, které se změní. Pokud region příští rok zruší letní čas, databáze tz vydá aktualizaci a každý vyhovující systém se automaticky přizpůsobí. Pevně zakódované `+1` dál navždy aplikuje loňskou politiku a tiše produkuje špatné časy.

Konkrétní příklad s ověřenými posuny

Naplánujte opakovaný hovor na každé pondělí v 09:00 v Berlíně, kterého se účastní někdo z Chicaga. Sledujte, jak se rozdíl v průběhu roku posouvá:

• Polovina ledna: Berlín je na CET (UTC+1), Chicago je na CST (UTC−6). Rozdíl je 7 hodin, takže hovor je v Chicagu ve 02:00.
• Polovina července: oba přešly na letní čas — Berlín CEST (UTC+2), Chicago CDT (UTC−5). Stále 7 hodin, takže stále 02:00 v Chicagu.
• Polovina března: obě země *nepřepínají* ve stejný den. V roce 2025 USA posunuly čas vpřed 9. března, ale EU až 30. března. Po ty tři týdny už bylo Chicago na CDT (UTC−5), zatímco Berlín byl stále na CET (UTC+1) — rozdíl pouhých 6 hodin, což znamená hovor v Chicagu ve 03:00.

Nástroj, který by uložil „Berlín = +1, Chicago = −6", by se v červenci *i* během březnových překryvných týdnů mýlil o hodinu. Jen systém, který vyhodnocuje pojmenovaná pásma vůči *konkrétnímu datu*, má každý týden správně. Přesně tak fungují plánovač schůzek a převodník Timezio: zeptají se, které místo máte na mysli, a poté aplikují živá pravidla pro dané datum místo zmrazeného čísla.

Praktický kontrolní seznam

Abyste mohli těžit z toho, jak databáze funguje, nikdy nepotřebujete otevřít soubor tzdata. Hodnotu do každodenního používání přenáší pět návyků:

• Ukládejte a sdílejte místa, ne posuny. „Jsem v `America/Los_Angeles`" přežije DST i změny politiky. „Jsem na UTC−8" nikoli.
• Udržujte své systémy aktualizované. Nejčastějším důvodem, proč jdou hodiny o víkendu přechodu špatně, je zařízení, které minulo nejnovější vydání `tzdata`. Aktualizace OS a aplikací jsou způsob, jak se k vám oprava dostane.
• Nedůvěřujte žádnému nástroji, který pro město zobrazuje jediný pevný posun. Pokud nedokáže zohlednit datum, nedokáže zohlednit DST.
• Překontrolujte přeshraniční události kolem víkendů se změnou času a po jakémkoli vládním oznámení. Právě tehdy mezera mezi pravidlem a aktualizací zaboří nejhlouběji.
• Berte každou odpověď jako prozatímní. Dnešní správný převod je správný jen do dalšího výnosu.

Databáze časových pásem IANA je jedním z nejtišších kusů sdílené infrastruktury na internetu — dobrovolníky udržovaná sada textových souborů, o kterou se digitální svět opírá v otázce občanského času. Funguje proto, že s časovými pásmy zachází jako s tím, čím skutečně jsou: pohyblivým cílem utvářeným politikou, nikoli pevnou mřížkou nakreslenou na mapě. Každý přesný převod, na který spoléháte, Timezio nevyjímaje, závisí na tom, že někdo, někde, zapsal nejnovější pravidlo a vydal jej dřív, než se hodiny změnily.