A számítógépes rendszereknek pillanatokat kell összehasonlítaniuk, rendezniük és szolgáltatások között továbbítaniuk. A Unix-idő egyszerű ötletet kínál: az 1970 eleji UTC epoch óta eltelt egységek száma. Egy szám könnyebben kezelhető, mint egy lokalizált dátum. Önmagában mégsem teljes szerződés. Ismerni kell az egységet, tartományt, pontosságot és azt, hogy az adat valóban globális pillanatot vagy csak emberi naptári szándékot ír-e le.

Az epoch közös referenciapontot ad

A Unix epoch 1970. január 1. 00:00:00 UTC. A pozitív értékek későbbi, a támogatott negatív értékek korábbi pillanatokat jelölnek. Ugyanaz az instant Budapesten és Tokióban más naptári időként jelenik meg, de az alapérték azonos.

A timestamp nem tartalmaz időzónát. A zóna a megjelenítéshez és naptári konverzióhoz szükséges.

A másodperc és milliszekundum nem találgatható

A hagyományos Unix timestamp másodperc, JavaScript gyakran milliszekundum, telemetry mikro- vagy nanoszekundum. A téves egység 1970 körüli vagy több ezer évvel későbbi dátumot eredményez.

Az API mezőnévben, típusban vagy dokumentációban nevezze meg az egységet. A számjegyek száma szerinti heurisztika történelmi és távoli dátumoknál elbukik.

Az UTC nem felhasználói naptár

Egy befejezett eseményt célszerű UTC instantként tárolni, majd a felület a választott zónába alakítja. ISO 8601 Z-vel vagy offsettel olvashatóbb lehet, mint egy puszta szám.

Az offset nélküli „02:30” DST-váltáskor kétszer vagy egyszer sem létezhet. Helyi tervhez timezone ID is kell.

A naptári érték nem mindig pillanat

Születésnap, fizetési határnap vagy „minden hétfőn kilenckor” helyi jelentést hordoz. Korai UTC-konverzió utazáskor vagy nyári időszámításkor eltolhatja.

A modell különböztesse meg az instantot, local date-et, local time-ot, zoned schedule-t és durationt.

A falióra ugrálhat

A rendszeróra szinkronizációkor előre vagy hátra korrigálható. Esemény időbélyegéhez megfelelő, művelet hosszának méréséhez nem.

Timeout és latency monotonic clockot használjon, amely a folyamat alatt nem csökken. Ez védi a lease-t és retry-t a negatív durationtől.

A sok tizedesjegy nem jelent valódi pontosságot

Nanoszekundumos típus mellett a hardware órája lehet sokkal pontatlanabb. Több esemény azonos timestampet kaphat, a hálózat pedig felcserélheti a beérkezést.

Stabil rendezéshez sequence, adatbázisverzió vagy logikai óra kell. Külön gépek timestampje nem kauzalitási bizonyíték.

A típus tartományát tesztelni kell

A 32 bites signed másodperc 2038-ban túlcsordul. A modern backend lehet 64 bites, miközben régi kliens, eszköz vagy adatbázisoszlop nem az.

A teszt távoli jövőt, epoch előtti időt és JavaScript serializációt is tartalmaz. Nagy integer stringként biztonságosabb lehet.

A leap second eltérő időmodelleket fed fel

Az UTC-t történelmileg szökőmásodperccel korrigálták, sok Unix-rendszer viszont minden napot 86 400 másodpercesnek kezel. Egyes platformok ismételnek, mások időben elkenik a korrekciót.

Átlagos üzleti alkalmazás ne implementálja kézzel, de pontos telemetry több platform között ismerje a források viselkedését.

Az óraszinkronizáció mérhető eltérést hagy

NTP nem jelenti, hogy minden node pontosan ugyanazt mutatja. Monitoring mérje az offsetet az autoritatív forráshoz képest. Nagy eltérés korai tokenlejáratot vagy jövőbeli eventet okozhat.

A protokoll kis maximális clock skew-t határoz meg. Súlyosan eltérő gépet ki kell venni az érzékeny munkából.

A timestamp nem globális sorrendgenerátor

Két process ugyanabban a milliszekundumban dolgozhat, óráik pedig eltérhetnek. CreatedAt szerinti rendezés tie-breaker nélkül nem stabil.

Doménváltozáshoz explicit aggregate version vagy broker offset megfelelőbb. A nagyobb timestamp nem biztos, hogy újabb kauzális információ.

A retention gyakran naptári szabály

A „hét évig megőrizni” jelentheti egy naptári év végétől számított időt, nem fix másodpercet. A leap year és helyi nap számít.

A rendszer tárolja a kezdőeseményt, policyt és kiszámított deadline-t audittal. Így később magyarázható a törlés.

Az adatbázis típusa is időmodellt választ

A különböző adatbázisok timestamp és datetime típusai nem azonos jelentésűek. Egyesek automatikusan UTC-re alakítanak, mások egyszerű naptári mezőket őriznek időzóna nélkül. Az ORM kényelmes típusa ezt a különbséget elrejtheti, majd szerverzóna-váltáskor vagy adatköltöztetéskor váratlan konverzió jelenik meg.

A séma tervezésekor ezért konkrétan meg kell határozni, mi kerül az oszlopba, milyen pontossággal és milyen konverzió történik az illesztőprogramban. A round-trip teszt ne csak ugyanazon a gépen fusson: eltérő processz-időzónával és nyári időszámítási dátummal is igazolja, hogy ugyanaz az instant tér vissza.

A külső rendszerek ideje bizonytalan bizonyíték

Egy mobilkliens által küldött createdAt lehet hibás óra, offline működés vagy szándékos manipuláció eredménye. Hasznos felhasználói eseményidő, de nem feltétlenül alkalmas jogosultsági határ, számlázási sorrend vagy csalásbiztos audit eldöntésére. A szerver fogadási ideje más kérdésre válaszol, ezért gyakran mindkettőt érdemes külön megőrizni.

Az esemény eredetéhez kapcsolódó bizalmi szintet a modellnek kell kifejeznie. Egy hiteles időbélyeg-szolgáltatás, egy saját adatközponti szerver és egy ismeretlen böngésző órája nem azonos bizonyító erejű, még akkor sem, ha mindhárom ugyanazt a numerikus formátumot küldi.

A formázás a végső, nem az első lépés

A felhasználónak szánt dátumszöveg nyelvtől, régiótól, naptártól és termékdöntéstől függ. A 03/04/2026 két különböző napot jelenthet, ezért adatcserében kerülendő, felületen pedig lokalizált formázó szükséges. A hónapnév, a hét kezdőnapja és a 12 vagy 24 órás kijelzés ne kézzel összefűzött string legyen.

A tárolt instantból csak a megjelenítés pillanatában készüljön helyi szöveg. Így a felhasználó zónaváltása, nyelvi beállítása vagy akadálymentességi igénye nem követel adatmigrációt, és az eredeti időérték továbbra is pontosan összehasonlítható marad.

A jó időmező megnevezi a jelentést

A createdAt, deadline, local date és duration külön név és típus. A szerződés leírja az egységet, zónát és inclusive határt.

A Unix-idő kiváló pillanatokhoz, de nem minden naptári kérdéshez. A jelentés meghatározása mindig megelőzi a reprezentációt.