Co je databáze časových pásem IANA
Pokud jste někdy v softwaru pracovali s daty a časy, spoléhali jste se na databázi časových pásem IANA, ať už jste o tom věděli, nebo ne. Vystupuje pod několika názvy – tz database, tzdata, Olsonova databáze nebo zoneinfo – ale všechny označují totéž: společný, volně dostupný katalog světových časových pásem a pravidel, která je řídí.
Slovo „katalog" jeho význam podceňuje. Databáze pouze neuvádí, které oblasti leží v jakém UTC offsetu. Zaznamenává úplnou historii občanského měření času pro každou oblast – každou změnu offsetu, každý přechod na letní čas, každé válečné posunutí hodin a každé plánované budoucí pravidlo – v mnoha případech až do poloviny 19. století, kdy místní střední čas ustoupil standardizovaným pásmům. Když vaše kalendářní aplikace správně ukáže, že se schůzka v roce 1985 konala o hodinu jindy než stejný čas na hodinách dnes, je to práce tz databáze.
Je textová, čitelná pro člověka a malá. Zkompilovaná binární podoba, která je součástí vašeho počítače, má jen několik megabajtů. Přesto v sobě ukrývá jeden z nejtišeji komplikovaných datových souborů ve výpočetní technice.
Krátká historie
Projekt začal v 80. letech 20. století pod vedením Arthura Davida Olsona, který sestavil první verzi a hostoval ji na serverech amerického Národního institutu zdraví (NIH). Po celá desetiletí byl udržován převážně dobrovolnickým úsilím koordinovaným prostřednictvím veřejné e-mailové konference, proto se v dokumentaci stále objevuje starší název „Olsonova databáze".
Paul Eggert převzal roli hlavního editora a zůstává dlouholetým koordinátorem projektu. Jeho sestavení doprovodného dokumentu theory.html a pečlivá historie revizí udělaly z databáze stejně tak historickou referenci jako technickou.
V roce 2011, po krátkém, ale znepokojivém právním sporu o historická data, přešla správa na Internet Assigned Numbers Authority (IANA), stejnou organizaci, která koordinuje další základní internetové zdroje. IANA nyní vydává oficiální verze, a proto se „databáze časových pásem IANA" stala kanonickým názvem. Práci stále vykonává stejná komunita přispěvatelů; IANA poskytuje institucionální zázemí a stabilní distribuční místo.
Konvence pojmenování: Oblast/Místo
Jednou z nejvýraznějších vlastností databáze je způsob, jakým pojmenovává pásma. Místo názvů zemí nebo holých offsetů používá formát Oblast/Místo, téměř vždy ukotvený k reprezentativnímu městu:
America/New_YorkEurope/LondonAsia/KolkataAustralia/Sydney
„Oblast" je obvykle kontinent nebo oceán (America, Europe, Asia, Pacific) a „Místo" je známé město v rámci pásma. Tato volba vypadá zvláštně, dokud nepochopíte úvahu, která za ní stojí.
Města jsou stabilní; politické hranice a offsety nikoli. Země se rozdělují, spojují, přejmenovávají a mění své hodiny. Město je naproti tomu pevný geografický bod s nepřetržitou historií měření času. Pojmenování pásma America/New_York místo „US Eastern Time" nebo „UTC-5" znamená, že identifikátor zůstává platný, i když se pravidla k němu připojená vyvíjejí.
Databáze se také záměrně vyhýbá názvům zemí, aby se vyhnula politickým sporům, a protože jedna země často obsahuje několik pásem – Spojené státy jich mají více než tucet. Jako neutrální označení vybírá nejlidnatější nebo historicky nejvýznamnější město v každém odlišném pásmu. Když dvě oblasti sdílejí od roku 1970 stejnou historii hodin, sdílejí jedno pásmo; jakmile se jejich historie rozejde, dostanou samostatné záznamy.
Proč holé offsety nestačí
Častým začátečnickým instinktem je uložit čas jako „UTC+5:30" a mít hotovo. To funguje pro jediný okamžik, ale selže ve chvíli, kdy potřebujete uvažovat o budoucích nebo opakujících se událostech, protože offsety nejsou statické vlastnosti místa. Jsou výstupem pravidel, která vlády neustále a často náhle mění.
Zvažte několik reálných příkladů, které databáze musela vstřebat:
- Samoa úplně přeskočila 30. prosince 2011. Aby svůj pracovní den sladila s Austrálií a Novým Zélandem místo se Spojenými státy, Samoa přeskočila Mezinárodní datovou hranici a přesunula se z UTC-11 na UTC+13. Pro každého na ostrovech ten pátek prostě neexistoval.
- Země ruší, zavádějí nebo mění letní čas s krátkým varováním. Evropská unie diskutovala o zrušení letního času; několik zemí a států USA změnilo svá pravidla pro letní čas v posledních desetiletích. Turecko, Rusko a další zcela posunuly své standardní offsety.
- Datumy začátku a konce letního času se posouvají. Spojené státy posunuly své hranice letního času v roce 2007. Jakýkoli systém, který měl staré pravidlo pevně zakódované, tiše produkoval špatné časy po týdny každý rok.
Pokud uložíte pouze offset, nemůžete odpovědět na otázku „jaký bude místní čas v Santiagu 15. listopadu příštího roku?" – protože odpověď závisí na pravidlech, která nemusí být ještě ani dokončena. Uložení identifikátoru pásma (America/Santiago) plus databáze umožňuje softwaru vypočítat správný offset pro jakýkoli okamžik, minulý nebo budoucí, a automaticky jej přepočítat, když se pravidla změní.
To je základní hodnotová nabídka: tz databáze odděluje identitu místa od neustále se měnících pravidel, která určují jeho hodiny.
Jak je udržována
Údržba probíhá otevřeně. Navrhované změny – nové pravidlo pro letní čas, opravené historické datum, vládní oznámení – jsou diskutovány na veřejné tz e-mailové konferenci, kde přispěvatelé jako důkazy uvádějí úřední věstníky, zpravodajské zprávy a vládní nařízení. Přesnost se bere vážně; změny historických dat jsou zvláště pečlivě prověřovány s primárními zdroji.
Verze jsou označovány rokem a písmenem: 2024a, 2024b, 2024c atd. Číslo je rok; písmeno se zvyšuje s každým vydáním v daném roce. Protože vlády oznamují změny hodin podle svých vlastních nepředvídatelných harmonogramů, neexistuje pevný harmonogram vydávání – v klidném roce mohou být dvě vydání, zatímco v roce politických změn jich bude mnoho. Očekává se, že systémy budou aktualizovat rychle, protože zastaralá databáze může znamenat zobrazení špatného času poté, co změna pravidel vstoupí v platnost.
Kdo na ní závisí
Téměř všechno.
- Operační systémy. Distribuce Linuxu dodávají
tzdatajako základní balíček. macOS odvozuje svá data časových pásem ze stejného zdroje. Windows používá z historických důvodů svá vlastní pásma založená na registru, ale vystavuje pásma IANA prostřednictvím knihovny ICU a moderních API. - Programovací jazyky. V podstatě každá vyspělá knihovna pro datum/čas čte z tz databáze nebo ji obsahuje: Pythonovo
zoneinfo, Javajava.time, projekt ICU, PostgreSQL, JavaScriptová jádra přes ICU, Ruby, PHP a mnoho dalších. - Aplikace. Kalendáře, rezervační systémy, platformy pro finanční obchodování, nástroje pro analýzu logů a plánovací služby se na ni spoléhají, obvykle aniž by na to jejich vývojáři mysleli.
Tato všudypřítomnost je přesně důvod, proč na databázi tolik záleží. Jediný, sdílený, pečlivě udržovaný zdroj pravdy znamená, že schůzka naplánovaná v jednom systému se zobrazí správně v jiném, napříč operačními systémy a jazyky, desítky let do minulosti nebo budoucnosti.
Pokud chcete prozkoumat samotná pásma, prohlédněte si úplný seznam Časová pásma IANA nebo se podívejte, jak jsou mapována po celém světě v našem adresáři Všechna časová pásma.
Často kladené otázky
Je tz databáze totéž co tzdata, zoneinfo a Olsonova databáze?
Ano. To vše jsou názvy pro stejný projekt. „tzdata" obvykle označuje datové soubory zabalené pro operační systém, „zoneinfo" zkompilovaný binární adresář a „Olsonova databáze" je starší historický název po zakladateli Arthuru Davidu Olsonovi. Dnes je oficiální název IANA Time Zone Database.
Jak často je databáze aktualizována?
Neexistuje pevný harmonogram. Vydání jsou spouštěna událostmi z reálného světa – vládou měnící pravidla pro letní čas nebo standardní offset, nebo opravou historických dat. Některé roky mají jediné vydání; jiné jich mají několik. Každé je pojmenováno jako 2024a, 2024b, s rostoucím písmenem v průběhu roku.
Proč pojmenovává pásma po městech jako America/New_York?
Města jsou geograficky pevná a mají nepřetržitou historii měření času, zatímco země, hranice a offsety se v čase mění. Použití reprezentativního města dává každému pásmu stabilní, politicky neutrální identifikátor, který zůstává platný, i když se změní základní pravidla pro letní čas nebo offset.
Mohu místo názvu pásma jednoduše uložit UTC offset?
Pouze pro jediný pevný okamžik. Pro budoucí nebo opakující se události byste měli uložit identifikátor pásma, protože offsety se mění s letním časem a vládními rozhodnutími. Název pásma plus databáze umožňuje softwaru automaticky vypočítat správný offset pro libovolné datum.
Kdo nyní projekt řídí?
Je publikován organizací IANA, která převzala správu v roce 2011, a koordinován Paulem Eggertem s komunitou přispěvatelů pracujících prostřednictvím veřejné tz e-mailové konference. Technická práce zůstává společným, dobrovolnickým úsilím.