Az időzóna nem egyszerűen egy UTC-hez hozzáadott szám. Egy régió történelmi és jövőbeli szabályainak adatbázisa. A +01:00 egyetlen pillanat kapcsolatát írja le, az Europe/Budapest viszont meghatározza a téli és nyári offsetet egy konkrét dátumhoz. Az alkalmazás hónapokig hibátlanul működhet, majd a DST-váltás egyetlen éjszakáján elbukhat.

Az offset és a timezone ID nem ugyanaz

Az offset egy már ismert helyi időt instanttá alakít. Nem mondja meg, milyen offset lesz ugyanabban a régióban jövőre. A jövő áprilisi kilenc óra régiót igényel.

A CET, CST vagy IST rövidítés több helyet is jelenthet. API-ban IANA azonosító vagy explicit offset használható a jelentés szerint.

Előreállításkor egyes helyi idők nem léteznek

A nyári időszámítás kezdetén az óra átugorhat egy intervallumot. A 02:30-nak nem lesz megfelelő instantja. A könyvtár elutasíthatja vagy eltolhatja, de az üzleti szabálynak kell döntenie.

Egy ébresztő talán a váltás után induljon, egy pénzügyi zárás viszont kérjen javítást. A technikai default nem ismeri a szándékot.

Visszaállításkor egy óra kétszer fordul elő

A DST végén ugyanaz a helyi idő két különböző offsettel létezhet. A parser választhatja az elsőt vagy másodikat, de a policy legyen dokumentált.

Csak local time-ot tartalmazó log úgy nézhet ki, mintha visszafelé haladna. Auditban UTC instant és szükség esetén eredeti zóna kell.

A szabályok politikai döntéssel változnak

Országok módosíthatják a DST dátumát, offsetet vagy megszüntethetik a nyári időt. Az IANA adatbázis frissül. Egy jövőbeli terv más UTC instantot kaphat update után.

A rendszernek el kell döntenie, a helyi szándékot vagy a korábban kiszámított instantot védi. Repülőjárat és heti meeting eltérhet.

A naptári nap nem mindig 24 óra

A „holnap kilenckor” nem ugyanaz, mint a „24 óra múlva”. DST-napon 23 vagy 25 óra is lehet. Az első calendar operation, a második duration.

A hónap sem fix másodperc. A hónap vége és február 29. explicit könyvtári policyt kér.

Csak UTC tárolása jövőbeli ismétlésnél kevés

Befejezett eseményhez UTC megfelelő. Ismétlődő tervnél elveszíti a helyi szándékot. Fix óraszám hozzáadásával a meeting DST után eltolódik.

A schedule local time-ot, timezone-t és recurrence rule-t őriz. Minden occurrence ezekből materializálódik.

A timezone adatbázisnak életciklusa van

Eltérő verziójú szerverek ugyanabból a tervből más instantot számíthatnak. A frissítés normál üzemeltetési feladat, kritikus zónák diffjével.

Fontos számításnál a tzdata verziója auditálható. Így a változás magyarázható és a jövőbeli események célzottan újraszámolhatók.

A felhasználónak látnia kell a kontextust

A „találkozó 10:00-kor” globális csapatnak hiányos. A UI mutassa a zónát vagy egyértelműen jelezze a helyi átszámítást.

A készülék zónája nem feltétlenül az esemény vagy fiók zónája. Szerkesztéskor legyen világos, helyi idő vagy abszolút instant változik.

A teszt ne csak januári delet használjon

Mindkét DST-váltás, hónap vége, szökőév, negatív offset, DST nélküli és félórás zóna is szerepeljen. A clock legyen kontrollálható.

Tzdata update fusson át regressziós teszten a valódi ügyfélrégiókkal, nem csak UTC-vel.

Az ismétlődő occurrence saját identitást igényel

Minden előfordulás stabil ID-t kaphat a tervből és a tervezett helyi időből. Szabályfrissítéskor megkülönböztethető az átszámítás egy új eseménytől.

A sorozat szerkesztése döntse el, egy alkalmat, a jövőt vagy az egész történetet változtatja. Kivételeket külön kell tárolni.

A tzdata-frissítés produkciós rollout

Telepítés előtt diff készülhet a jövőbeli foglalásokhoz. Egyórás változás értesítést és jobok újratervezését igényelheti.

Clusterben koordinált frissítés kell. A verzió kerüljön diagnostics-ba, hogy ugyanazt a számítást minden worker végezze.

A történelmi megjelenítésnek két legitim célja van

Egy régi esemény modern tzdata alapján más helyi offsetet kaphat. Auditdokumentum esetén az eredeti megjelenített időt és offsetet is meg kell őrizni.

Más riport a jelenlegi legjobb történelmi tudást akarhatja. A terméknek meg kell neveznie, reprodukciót vagy újraszámítást végez.

A felhasználó zónája nem mindig követi a készüléket

Utazáskor a telefon automatikusan új zónára válthat, miközben egy vállalati fiók továbbra is a budapesti iroda idejében dolgozik. Egy légitársasági alkalmazás az indulási és érkezési repülőtér helyi idejét mutatja, nem feltétlenül az utas aktuális zónáját. A „helyi idő” tehát csak akkor értelmes, ha megnevezzük, mihez helyi.

A terméknek külön kell kezelnie az esemény zónáját, a fiók alapértelmezését és a megjelenítő eszköz beállítását. Automatikus választás megengedhető, de a felület tegye láthatóvá és módosíthatóvá. Kritikus határidőnél az offset vagy zónanév kiírása olcsóbb, mint egy félreértett találkozó.

A locale és az időzóna két külön beállítás

A magyar nyelvet használó ember élhet Londonban, az angol felületet választó csapat pedig működhet Tokióban. A locale a dátum formáját, hónapnevet és nyelvet vezérli; a timezone azt, melyik falióraérték tartozik az instanthoz. Az egyikből nem szabad automatikusan kikövetkeztetni a másikat.

Az API-ban is külön mezőként érdemes továbbítani őket. Így a frontend nem böngészőnyelvből találgat zónát, a backend pedig nem országkódból választ olyan naptári szabályt, amely egy utazó vagy nemzetközi szervezet esetében hibás.

A támogatott zónák listája változó adat

Az IANA azonosítók között vannak történelmi aliasok és átnevezések. Egy korábban eltárolt név továbbra is működhet, de az új felületen célszerű a kanonikus, emberileg érthető választást mutatni. A zónát nem kell minden deploynál statikus enumként újra feltalálni.

A kereső városneveket és aktuális offsetet mutathat, de az offset önmagában ne legyen tartós azonosító. Mentéskor a rendszer validálja a zónát a telepített adatbázissal, frissítéskor pedig megőrzi a régi értékek olvashatóságát és dokumentálja az aliaskezelést.

Az időzóna a jelentés része

Ha a modell külön őrzi az instantot, régiót és helyi szándékot, a szezonális átmenet tesztelt ág lesz.

Az időzóna nem utólagos prezentációs részlet. A felhasználói ígéret, scheduler és audit ugyanarra a modellre épül.