Časová zóna není jen číslo přičtené k UTC. Je to sada pravidel, která říká, jak se konkrétní okamžik zobrazí v určité oblasti, včetně historických změn a politických rozhodnutí. Pevný offset +01:00 popisuje jeden vztah v jednom okamžiku, zatímco zóna Europe/Prague umí určit zimní i letní čas pro konkrétní datum. Aplikace, která tyto pojmy zamění, může fungovat měsíce a selhat právě při sezónním přechodu.

Offset a identifikátor zóny nesou jiné informace

Offset jednoznačně pomůže převést již známý místní čas na okamžik, ale neříká, jaký offset bude ve stejné oblasti příští rok. Identifikátor z databáze IANA odkazuje na pravidla pro minulost i budoucnost. Proto plán „příští duben v devět v Praze“ potřebuje zónu, ne pouze dnešní offset.

Zkratky jako CET, CST nebo IST jsou pro výměnu dat nevhodné. Mohou označovat několik regionů a někdy se jejich význam mění podle sezóny. Rozhraní má používat standardní identifikátor nebo explicitní offset podle toho, zda popisuje pravidlo, či hotový okamžik.

Při posunu vpřed některé místní časy neexistují

Na začátku letního času se hodiny v mnoha oblastech posunou dopředu a část noci přeskočí. Plán na 02:30 tak nemusí mít žádný odpovídající okamžik. Knihovna může hodnotu odmítnout, posunout na první platný čas nebo použít jiné výchozí pravidlo. Tiché chování bez doménového rozhodnutí vede k překvapivým schůzkám a jobům.

Aplikace musí určit, co uživatel zamýšlel. U budíku může být vhodné spustit jej po přechodu, u finanční uzávěrky může být lepší vstup odmítnout a vyžádat opravu. Technická knihovna nedokáže sama rozhodnout business význam.

Při posunu zpět se čas opakuje

Na konci letního času se jedna hodina objeví dvakrát. Text „02:30“ pak odpovídá dvěma různým okamžikům s odlišným offsetem. Bez dalšího pravidla nelze poznat, který z nich autor myslel. Parser může vybrat první nebo druhý, ale implicitní volba musí být známá a testovaná.

Logy používající pouze místní čas mohou vypadat, jako by se události vrátily do minulosti. Pro audit je proto vhodné uchovávat UTC instant a případně i původní zónu, aby šlo reprodukovat uživatelské zobrazení.

Pravidla se mohou změnit po uložení plánu

Státy mění termíny přechodů, ruší letní čas nebo upravují offset s krátkým předstihem. Databáze časových zón proto dostává aktualizace. Událost naplánovaná mnoho měsíců dopředu může po aktualizaci pravidel odpovídat jinému UTC okamžiku, i když její místní záměr zůstává stejný.

Systém musí vědět, zda chrání původně vypočtený instant, nebo místní čas podle aktuálních pravidel. Letecký odlet a globální vysílání mohou mít jiné požadavky než týdenní schůzka. U důležitých plánů je užitečné uložit místní hodnotu, zónu i tehdy vypočtený instant a změny sledovat.

Kalendářní den nemá vždy 24 hodin

Přičíst 24 hodin není totéž jako přejít na stejný místní čas následujícího dne. Během přechodu může mít den 23 nebo 25 hodin. Pro „zítra v devět“ se má použít kalendářní operace v zóně; pro „za přesně 24 hodin“ skutečné trvání na časové ose.

Stejný rozdíl platí pro měsíce a roky. Měsíce mají různou délku a 29. únor nemá každý rok následníka. Datumová knihovna potřebuje explicitní politiku pro konec měsíce, nikoli aproximaci v sekundách.

Uložení pouze UTC někdy nestačí

Pro dokončenou událost je UTC instant často ideální. Pro budoucí opakování však může ztratit místní záměr. Pokud uložíme jen první výskyt přepočtený do UTC a další vytváříme pevným intervalem, schůzka se po změně času posune o hodinu.

Plánované pravidlo má zachovat lokální čas, IANA zónu a popis opakování. Každý výskyt se vypočítá podle pravidel platných pro jeho datum. Vygenerovaný instant lze následně uložit pro spolehlivé provedení.

Testy musí překročit běžný pracovní den

Časové testy často používají poledne uprostřed ledna, kde většina chyb není vidět. Potřebují zahrnout oba DST přechody, konec měsíce, přestupný rok, záporný offset, oblast bez letního času a zónu s necelou hodinou posunu. Hodiny i aktuální datum mají být v testu ovladatelné.

Aktualizace timezone databáze by měla být součástí údržby stejně jako bezpečnostní update knihovny. Rozdílné verze na serverech mohou vypočítat jiný okamžik ze stejného plánu.

Verzi pravidel je užitečné zaznamenat u dávkových výpočtů a citlivých plánů. Když aktualizace změní budoucí výskyty, tým pak dokáže vysvětlit rozdíl a cíleně přepočítat jen dotčené záznamy. Nasazení nové databáze má projít porovnáním důležitých zón v plánovacím horizontu produktu. Takový diff zachytí politickou změnu dříve, než se projeví v notifikacích, rezervacích nebo výplatách.

Uživatelé dotčeného plánu mohou potřebovat upozornění, zejména když se již potvrzený místní čas po aktualizaci pravidel začne mapovat na jiný okamžik. Transparentní změna je bezpečnější než tichý přepočet, který každý účastník zjistí až podle opožděné události.

Uživatel potřebuje vidět zvolený kontext

Rozhraní má ukázat časovou zónu u událostí, které mohou číst lidé z různých oblastí. Text „v 10:00“ je neúplný; „10:00 Europe/Prague“ nebo lokální zobrazení s vysvětlením původu snižuje omyly. Při zadávání může aplikace nabídnout výchozí zónu, ale nesmí ji potichu zaměnit za zónu zařízení v každé situaci.

Časové zóny nejsou okrajová komplikace, nýbrž součást významu data. Spolehlivý systém rozlišuje instant, offset a regionální pravidla, zachovává uživatelský záměr a explicitně řeší neexistující či dvojznačné časy. Pak sezónní změna není překvapení, ale běžně testovaná větev.