Počítač potrebuje okamihy porovnávať, triediť a prenášať medzi službami. Unixový čas ponúka jednoduchú reprezentáciu: počet jednotiek od začiatku roka 1970 v UTC. Jedno číslo sa spracúva ľahšie než lokálny dátum s názvom mesiaca. Samotná hodnota však nie je úplná zmluva. Systém musí poznať jednotku, rozsah, presnosť a to, či údaj naozaj opisuje bod na globálnej osi alebo iba kalendárny zámer človeka.

Epocha vytvára spoločný referenčný bod

Unixová epocha začína 1. januára 1970 o polnoci UTC. Kladné hodnoty označujú neskoršie okamihy a niektoré systémy podporujú záporné hodnoty pre staršie dáta. Rovnaký instant možno zobraziť v Bratislave aj Tokiu inak, no číselná identita zostane rovnaká.

Timestamp neobsahuje timezone. Zóna sa použije až pri prevode do kalendára pre používateľa. Zamieňať UTC instant za lokálny zápis vedie k posunom.

Sekundy a milisekundy sa nedajú hádať bezpečne

Tradičný timestamp používa sekundy, JavaScript často milisekundy a telemetry mikrosekundy či nanosekundy. Zámena posunie dátum k roku 1970 alebo tisíce rokov do budúcnosti.

API má jednotku uviesť v názve, type alebo dokumentácii. Heuristika podľa počtu číslic zlyhá pri historických a vzdialených hodnotách a skrýva porušený kontrakt.

UTC nie je používateľský kalendár

Backend obyčajne ukladá dokončený okamih v UTC a zobrazenie prevedie do vybranej zóny. ISO 8601 string s Z alebo offsetom je pre API často čitateľnejší než holé číslo a stále jednoznačný.

Text „02:30“ bez offsetu nemusí označovať jediný instant. Počas zmeny letného času môže nastať dvakrát alebo vôbec.

Kalendárny údaj nie je vždy instant

Narodeniny, dátum splatnosti alebo „každý pondelok o deviatej“ majú lokálny význam. Ak sa okamžite premenia na UTC timestamp, môžu sa pri zmene zóny alebo DST posunúť.

Model má rozlišovať instant, local date, local time, zoned schedule a duration. Jeden univerzálny typ iba presunie nejasnosť do ďalších vrstiev.

Wall clock môže skočiť

Systémové hodiny sa synchronizujú a môžu byť korigované dopredu alebo dozadu. Sú vhodné na čas udalosti, nie na meranie trvania requestu. Timeout a latency používajú monotónne hodiny, ktoré počas procesu neklesajú.

Rozdiel chráni retry, lease a lock pred negatívnou alebo nečakane dlhou duration po korekcii času.

Veľa desatinných miest neznamená presné meranie

Nanosekundový typ neznamená, že hardware pozná čas s nanosekundovou presnosťou. Viac udalostí môže dostať rovnakú hodnotu a sieť zmení poradie doručenia.

Pre stabilné zoradenie sa pridáva sekvenčné ID, databázová verzia alebo logický čas. Timestamp medzi uzlami nie je dôkaz kauzality.

Rozsah typu sa musí testovať

32-bitový signed počet sekúnd narazí v roku 2038 na hranicu. Moderný backend môže používať 64 bitov, no staré zariadenie, knižnica alebo databázový stĺpec nie.

Testy zahŕňajú vzdialenú budúcnosť, obdobie pred epochou a prechod cez serializáciu do JavaScriptu, ktorý nemá presnú reprezentáciu každého 64-bit integeru.

Leap seconds odhaľujú rozdiel časových modelov

UTC bolo historicky upravované priestupnou sekundou, zatiaľ čo veľa Unix implementácií modeluje deň ako 86 400 sekúnd. Platformy môžu sekundu zopakovať alebo rozložiť korekciu na interval.

Bežná aplikácia ju nemá implementovať ručne, ale presná telemetry integrácia potrebuje vedieť, ako sa správajú operačné systémy a poskytovateľ času.

Serializácia potrebuje stabilnú reprezentáciu

Číslo v JSON môže stratiť presnosť. Bezpečnou alternatívou je decimal string alebo štandardný ISO formát. Databáza, API aj klient musia zachovať rovnaký instant a rozlíšenie.

Konverzia patrí do jednej testovanej vrstvy. Opakované delenie a násobenie medzi jednotkami vedie k overflow alebo zaokrúhleniu.

Dobrá časová zmluva pomenúva význam

Pole má hovoriť, či ide o createdAt, deadline, lokálny dátum alebo dobu trvania. Dokumentácia uvedie timezone, jednotku a inclusive hranicu.

Unix time je výborný pre body na osi. Nie je odpoveďou na všetky kalendárne otázky. Najprv treba určiť význam a až potom zvoliť reprezentáciu.

Synchronizácia hodín má merateľnú odchýlku

NTP alebo cloud time service neznamená, že všetky uzly ukazujú úplne rovnaký čas. Monitoring má sledovať offset voči autoritatívnemu zdroju a upozorniť na prekročenie tolerancie. Stroj s výraznou odchýlkou môže vydávať predčasne expirované tokeny, zlé certifikáty alebo udalosti zoradené do budúcnosti.

Bezpečné protokoly definujú maximálny clock skew a nesnažia sa ho kompenzovať neobmedzene. Ak je odchýlka veľká, uzol sa vyradí z citlivej práce alebo sa incident rieši na infraštruktúrnej vrstve.

Timestamp nie je globálny generátor poradia

Dva procesy môžu vytvoriť udalosť v rovnakej milisekunde a ich hodiny môžu byť posunuté. Zoradenie iba podľa createdAt preto nemusí byť stabilné. Pagination aj event processing potrebujú druhý tie-breaker, napríklad ID alebo sequence.

Pri doménových zmenách je vhodná explicitná verzia agregátu. Vyšší timestamp od iného uzla nemusí znamenať novšiu kauzálnu informáciu. Logical clocks alebo broker offset riešia poradie v presne vymedzenom prúde.

Retencia a právne termíny sú kalendárne pravidlá

„Uchovať sedem rokov“ nemusí znamenať pevný počet sekúnd. Právna politika môže vychádzať z konca kalendárneho roka, lokálneho dňa alebo business udalosti. Jednorazový prevod na duration môže zlyhať na priestupných rokoch.

Model má uložiť začiatok, pravidlo a vypočítaný deadline s auditom. Pri zmene politiky možno vysvetliť, prečo bol konkrétny záznam odstránený alebo zachovaný.

Výpočet sa testuje na hranici roka aj timezone.

Výsledok musí zostať úplne stabilný naprieč všetkými oficiálne podporovanými klientmi a databázovými drivermi dlhodobo.