Čas v aplikaci není pouze hodnota z funkce now(). Ovlivňuje expiraci tokenů, plánování úloh, fakturaci, pořadí událostí, cache i uživatelské připomínky. Chyby se často objeví až při výpadku, změně zóny nebo opakovaném doručení zprávy. Spolehlivý návrh proto zachází s časem jako s explicitní závislostí a doménovou veličinou. Rozlišuje, zda potřebuje okamžik, kalendářní pravidlo, dobu trvání nebo pouze relativní deadline.

Význam se stanoví před datovým typem

Sloupec nazvaný date nebo timestamp neříká, co hodnota znamená. Je to čas vytvoření záznamu, uživatelský termín, okamžik přijetí události, nebo plánovaný lokální čas? Každá možnost vyžaduje jiné konverze a pravidla změny.

Názvy a typy mají význam zachytit. Instant se ukládá jednoznačně v UTC, lokální datum zůstává datem bez umělé půlnoci a opakovaný plán nese zónu. Takový model zabraňuje tomu, aby různé vrstvy hádaly původní záměr.

Hodiny mají být nahraditelná závislost

Přímé volání systémového času rozptýlené po kódu ztěžuje testování expirace a hraničních okamžiků. Aplikace může používat clock službu nebo injektovaný zdroj času. Produkce vrací skutečné hodiny, test nastaví přesný instant a může jej kontrolovaně posunout.

To umožní ověřit chování těsně před a po deadline, během DST přechodu i při dlouhém zpracování. Test nemusí čekat ani záviset na momentu spuštění. Jednotný zdroj také usnadní audit, která část systému rozhodla na základě jakého času.

Deadline a duration patří k monotónním hodinám

Timeout requestu, délka jobu nebo interval retry se nemá měřit kalendářními hodinami, které se mohou synchronizací posunout. Monotónní hodiny zaručují, že měřená hodnota během procesu neklesne. Kalendářní čas se používá pro záznam události a komunikaci s okolím.

Deadline přenášený mezi stroji potřebuje opatrnost, protože každý uzel má jiné hodiny a síť přidává zpoždění. Protokol může poslat absolutní limit s tolerancí nebo zbývající dobu a na každém hopu ji zmenšit. Volba musí být součást smlouvy.

Naplánovaná úloha se může spustit pozdě nebo dvakrát

Scheduler není dokonale přesný. Proces může být vypnutý, fronta přetížená a lease může vypršet těsně před dokončením práce. Systém proto nemá předpokládat přesně jedno provedení v ideální sekundě. Úloha potřebuje idempotentní operaci, stabilní identifikátor výskytu a pravidlo pro zmeškané spuštění.

Po obnovení může být správné provést všechny zmeškané výskyty, pouze poslední, nebo žádný. Fakturace, synchronizace statistiky a marketingová notifikace mají jiné požadavky. Scheduler má technicky umožnit volbu, ale rozhodnutí patří doméně.

Expirace není automatické fyzické smazání

Když token nebo záznam expiruje v určitý okamžik, rozhodovací cesta jej od té chvíle nesmí přijmout. Cleanup job může data odstranit později. Spoléhat na to, že přesně o půlnoci proběhne mazání, vytváří okno, ve kterém expirovaná položka stále funguje.

Validace má porovnat deadline s autoritativním časem a jasně definovat hranici, například zda je hodnota platná při přesné rovnosti. Cleanup řeší kapacitu a soukromí, nikoli samotné bezpečnostní rozhodnutí.

Distribuované události mohou přijít mimo pořadí

Timestamp producenta nepředstavuje spolehlivé globální pořadí. Hodiny mohou být posunuté a zpráva se může zdržet v síti. Spotřebitel má používat doménovou verzi, sekvenční číslo nebo idempotency key, když potřebuje určit novější stav.

Je užitečné rozlišovat event time, kdy událost podle zdroje nastala, a processing time, kdy ji systém zpracoval. Analytika i stream processing potřebují pravidlo pro opožděná data a dobu, po kterou jsou ochotny přepočítávat výsledky.

Cache a lease potřebují bezpečnostní rezervu

TTL v distribuované cache není přesný alarm. Záznam může být odstraněn později a různé vrstvy mají vlastní čas. Aplikace musí umět ověřit skutečnou platnost dat, pokud na ní závisí bezpečnost. Obnova před vypršením může používat jitter, aby tisíce položek neexpirovaly současně.

U distribuovaného locku nestačí získat lease na určitý čas. Pomalý vlastník může pokračovat po vypršení, zatímco jiný již získal nový zámek. Fencing token nebo verze operace chrání cílový zdroj před zastaralým vlastníkem.

Pozorovatelnost musí zachovat kontext

Log události má používat jednoznačný instant s dostatečnou přesností a korelační identifikátor. Pro uživatelský plán je zároveň vhodné zaznamenat zónu a lokální záměr. Dashboard má rozlišit zpoždění fronty, dobu zpracování a rozdíl mezi plánovaným a skutečným spuštěním.

Alert na „pozdní job“ potřebuje toleranci odpovídající doméně. Bez ní krátký posun hodin nebo běžná fronta vytvoří falešné incidenty, zatímco skutečně ztracený výskyt zůstane skrytý v průměru.

Časové scénáře patří do testovací matice

Vedle běžného průchodu je nutné testovat rovnost s deadline, opakované doručení, obnovení po výpadku, změny DST, konec měsíce, přestupný den a rozdílné pořadí událostí. Integrační test má používat stejné databázové typy a serializaci jako produkce.

Provozní postup má určit také ruční zásah. Operátor potřebuje bezpečně znovu spustit konkrétní výskyt, přeskočit chybný plán a zjistit, zda vedlejší efekt už proběhl. Stabilní identifikátor a audit rozhodnutí chrání před dvojitou platbou či notifikací. Hromadný replay po výpadku se má dávkovat a sledovat, protože náhlé spuštění všech zmeškaných úloh může přetížit závislé služby více než původní incident.

Stejné ovládání má být dostupné bez přímých zásahů do databáze, které obcházejí audit a validační pravidla.

Spolehlivý časový systém nepředstírá dokonale synchronní svět. Explicitně modeluje nejistotu, zpoždění a opakování. Když jsou hodiny ovladatelné, operace idempotentní a kalendářní záměr zachovaný, čas přestane být skrytou globální proměnnou a stane se testovatelnou součástí architektury.