Časové pásmo nie je iba číslo pripočítané k UTC. Je to databáza historických a budúcich pravidiel pre konkrétny región. Offset +01:00 opisuje vzťah v jednom okamihu, zatiaľ čo Europe/Bratislava vie určiť zimný a letný čas pre konkrétny dátum. Aplikácia, ktorá tieto pojmy zamení, môže fungovať väčšinu roka a zlyhať počas jedinej noci zmeny.

Offset a timezone ID nesú inú informáciu

Offset pomôže previesť hotový lokálny zápis na instant. Nehovorí, aký bude vzťah v rovnakom regióne o rok. Budúca schôdzka o deviatej potrebuje IANA timezone ID.

Skratky CET, CST či IST sú nejednoznačné a nevhodné pre API. Kontrakt používa región alebo explicitný offset podľa typu údaja.

Pri posune dopredu niektoré časy neexistujú

Na začiatku letného času sa časť noci preskočí. Lokálnych 02:30 nemusí mať žiadny instant. Knižnica môže vstup odmietnuť alebo ho posunúť, no business pravidlo musí byť vedomé.

Budík sa možno spustí po prechode, finančná uzávierka môže vyžadovať opravu. Technická default hodnota nepozná doménový zámer.

Pri návrate sa jedna hodina opakuje

Na konci DST zodpovedá 02:30 dvom okamihom s odlišným offsetom. Parser môže vybrať prvý či druhý, ale voľba musí byť dokumentovaná a testovaná.

Log s iba lokálnym časom potom vyzerá, akoby sa udalosti vrátili. Audit má ukladať UTC instant a podľa potreby pôvodnú zónu.

Pravidlá sa menia politickým rozhodnutím

Štát môže zmeniť termín DST, offset alebo letný čas zrušiť. IANA timezone database sa preto aktualizuje. Budúci plán môže po update zodpovedať inému UTC instantu.

Systém musí rozhodnúť, či chráni lokálny zámer alebo už vypočítaný instant. Let, vysielanie a pravidelná porada môžu mať odlišnú politiku.

Kalendárny deň nemá vždy 24 hodín

„Zajtra o deviatej“ nie je to isté ako „o 24 hodín“. Počas DST má deň 23 alebo 25 hodín. Prvá operácia je kalendárna v zóne, druhá duration na časovej osi.

Mesiac tiež nie je pevný počet sekúnd. Knižnica potrebuje pravidlo pre koniec mesiaca a 29. február.

Uložiť iba UTC niekedy nestačí

Pre dokončenú udalosť je UTC ideálne. Pri budúcom opakovaní však stratí lokálny zámer. Ak ďalšie výskyty vzniknú pridaním pevného počtu hodín, schôdzka sa po DST posunie.

Schedule uchová local time, timezone a recurrence rule. Konkrétny výskyt sa potom materializuje ako instant podľa aktuálnych pravidiel.

Timezone database potrebuje lifecycle

Servery s odlišnou verziou pravidiel môžu z rovnakého plánu vypočítať iný výsledok. Update patrí do bežnej údržby a nasadenie má porovnať kritické zóny v plánovacom horizonte.

Pri citlivom výpočte je užitočné zaznamenať verziu databázy. Zmena sa potom dá vysvetliť a dotknuté výskyty cielene prepočítať.

Používateľ potrebuje vidieť časový kontext

Text „stretnutie o 10:00“ je pre globálny tím neúplný. UI má ukázať timezone alebo previesť čas do lokálneho zobrazenia s jasným pôvodom. Automatická zóna zariadenia nemusí zodpovedať účtu či miestu udalosti.

Pri editácii budúceho plánu má používateľ vedieť, či mení lokálny čas alebo absolútny instant.

Testy musia prekročiť bežné poludnie

Sada obsahuje oba DST prechody, leap day, koniec mesiaca, záporný offset, zónu bez DST a posun o pol hodiny či 45 minút. Hodiny sú v teste ovládateľné.

Update timezone databázy spustí regresné scenáre. Produkčné fixture používa skutočné regióny zákazníkov, nie iba UTC.

Notifikácia môže potrebovať prepočet

Ak sa pravidlo regiónu zmení po naplánovaní, pripomienka uložená ako starý UTC instant môže prísť v nesprávnom lokálnom čase. Systém má vedieť budúce joby prepočítať a používateľa upozorniť na významnú zmenu.

Timezone je súčasť významu, nie prezentačný detail. Keď model zachová instant, región a zámer oddelene, sezónne prechody sa stanú testovanou vetvou namiesto prekvapenia.

Opakované pravidlo potrebuje vlastnú identitu

Každý výskyt pravidelnej udalosti má stabilný occurrence ID odvodený od plánu a lokálneho zamýšľaného času. Ak sa timezone pravidlá aktualizujú, systém vie rozlíšiť prepočet existujúceho výskytu od vytvorenia nového. To je dôležité pre notifikácie, RSVP aj idempotentné joby.

Editácia série musí povedať, či mení iba jeden výskyt, budúce výskyty alebo celú históriu. Kalendárové aplikácie preto uchovávajú výnimky a pôvodné recurrence pravidlo, nie iba zoznam UTC timestampov.

Zmena databázy pásiem je produkčný rollout

Pred nasadením novej verzie možno vypočítať diff budúcich udalostí v regiónoch, ktoré produkt používa. Zmena o hodinu pri tisícoch rezervácií si môže vyžiadať upozornenie používateľov a preplánovanie jobov.

V clusteri sa update nasadzuje koordinovane. Ak polovica workerov používa staré pravidlá, rovnaký job môže dostať rozdielny instant podľa toho, ktorý uzol ho spracuje. Verzia timezone dát patrí do diagnostics a deployment kontroly.

Historický čas tiež nie je nemenný dataset

IANA databáza občas opravuje historické informácie. Report pre udalosť spred desaťročí sa po update môže zobraziť s iným lokálnym offsetom, hoci uložený UTC instant zostal rovnaký. Auditný systém môže potrebovať zachovať aj vtedy použitý offset alebo rendered text.

Produkt musí rozlíšiť reprodukciu historického dokumentu od moderného prepočtu podľa najlepších súčasných znalostí. Obe možnosti sú legitímne, no majú odlišný účel.

Rozhodnutie sa uvedie v exporte aj auditnej dokumentácii, aby používateľ vedel, prečo sa zobrazený lokálny čas môže líšiť od staršieho reportu. Kritický historický dokument môže uchovať pôvodný offset a rendered label ako súčasť nemenného záznamu.

Taký záznam sa už automaticky neprepisuje novšími pravidlami.