Počítačové systémy potřebují ukládat okamžiky tak, aby je mohly porovnat, seřadit a přenést mezi službami. Unixový čas nabízí jednoduchou myšlenku: vyjádřit okamžik jako počet jednotek uplynulých od začátku roku 1970 v UTC. Jediné číslo působí univerzálněji než datum napsané v místním formátu. Tato jednoduchost je užitečná, ale neřeší všechny otázky. Systém stále musí znát jednotku, přesnost, původ hodin a rozdíl mezi skutečným okamžikem a kalendářním údajem zamýšleným člověkem.

Epocha vytváří společný referenční bod

Unixová epocha začíná 1. ledna 1970 v 00:00:00 UTC. Kladná čísla označují pozdější okamžiky, záporná mohou představovat starší data. Protože hodnota není spojena s místním zápisem, dva systémy mohou porovnat události bez ohledu na to, zda je uživatel vidí v Praze, Tokiu nebo New Yorku.

Timestamp sám neobsahuje časovou zónu. Představuje bod na časové ose. Zónu potřebujeme až při převodu do kalendářního data pro člověka. Zobrazení stejného okamžiku může mít jiné datum i hodinu, ale podkladová událost zůstává stejná.

Sekundy, milisekundy a mikrosekundy nejsou zaměnitelné

Tradiční Unix timestamp používá sekundy, JavaScript často pracuje s milisekundami a databáze či telemetrie mohou používat mikrosekundy nebo nanosekundy. Číslo bez uvedené jednotky je neúplná smlouva. Záměna sekund za milisekundy posune datum o tisíce let nebo naopak vytvoří hodnotu blízko počátku epochy.

API má jednotku vyjádřit názvem pole, typem nebo dokumentací a testovat realistický rozsah. Převod by měl probíhat v jedné jasné vrstvě. Heuristika podle počtu číslic může krátkodobě zachránit nečistá data, ale jako trvalé rozhraní skrývá chyby a selhává u historických či vzdálených hodnot.

UTC není formát zobrazení

UTC poskytuje společnou časovou základnu, nikoli uživatelsky přívětivý kalendář. Backend obvykle ukládá skutečné okamžiky v UTC a až klient nebo prezentační vrstva je převádí do zvolené zóny. Řetězec ISO 8601 s Z nebo explicitním offsetem může být pro rozhraní čitelnější než holé číslo a stále jednoznačně popisovat okamžik.

Naopak text bez offsetu, například „2026-10-25 02:30“, nemusí určovat jediný okamžik. Během změny letního času může nastat dvakrát nebo vůbec. Pokud vstup představuje místní plán, musí spolu s datem nést identifikátor zóny a pravidlo pro nejednoznačné či neexistující časy.

Kalendářní hodnota není vždy okamžik

Narozeniny, účetní den, datum splatnosti nebo „každé pondělí v devět“ nejsou totožné s bodem na globální ose. Převést je při vytvoření na timestamp může zničit záměr. Narozeniny se nemají posunout při cestě do jiné zóny a pravidelná porada má často zůstat v místních devět i po změně letního času.

Datový model má rozlišovat instant, lokální datum, lokální čas, zónované datum a trvání. Jediný univerzální timestamp je lákavý, ale přenáší nejasnost do každé pozdější operace.

Systémové hodiny mohou skočit

Hodiny počítače se synchronizují a mohou být opraveny dopředu nebo dozadu. Wall clock je vhodný pro skutečný čas události, ale není spolehlivý pro měření délky operace. Timeout nebo latency se má měřit monotónními hodinami, které během běhu procesu neklesají.

Rozdíl je důležitý u retry, lease a distribuovaných zámků. Výpočet „aktuální timestamp minus start“ může po korekci hodin vytvořit zápornou či příliš dlouhou dobu. Knihovny obvykle nabízejí oddělené API pro kalendářní čas a monotónní měření.

Přesnost neznamená přesnost měření

Hodnota s devíti desetinnými místy nevypovídá, zda zdrojové hodiny skutečně měří nanosekundy. Několik událostí může získat stejný timestamp a pořadí může ovlivnit fronta nebo síť. Pro jednoznačné řazení je vhodný doplňkový sekvenční identifikátor, databázová verze nebo logická časová značka.

V distribuovaném systému navíc nejsou hodiny dokonale synchronní. Událost zaznamenaná s vyšším timestampem nemusela kauzálně nastat později. Timestamp je důležitá evidence, nikoli úplný důkaz pořadí mezi nezávislými uzly.

Rozsah a typ jsou součástí návrhu

Historické 32bitové signed reprezentace sekund narazí v roce 2038 na limit. Moderní systémy často používají 64 bitů, ale problém se může skrývat v knihovně, databázovém sloupci, externím zařízení nebo starším protokolu. Testy mají zahrnout vzdálenější budoucnost i data před epochou, pokud je doména dovoluje.

Při serializaci do prostředí s omezenou přesností celých čísel je bezpečnější použít řetězec nebo standardní datumový formát. Přesný typ musí přežít celou cestu od databáze přes JSON až k uživatelskému rozhraní.

Přestupné sekundy odhalují rozdíl mezi civilním a technickým časem

UTC bylo historicky občas upraveno přestupnou sekundou, zatímco mnoho Unixových implementací modeluje každý den jako 86 400 sekund. Systémy tuto odchylku řeší různě: některé sekundu opakují, jiné ji rozmažou během delšího intervalu. Běžná business aplikace ji nemusí počítat ručně, ale musí vědět, jak se chová operační systém, databáze a poskytovatel času. U přesné telemetrie nebo integrace několika platforem může odlišná strategie vytvořit zdánlivě duplicitní či posunuté události.

Dobrá časová smlouva je explicitní

Spolehlivé rozhraní pojmenuje jednotku, přesnost a význam hodnoty. U okamžiku stanoví UTC či povinný offset; u místního plánu zachová časovou zónu a kalendářní záměr. Validace kontroluje rozsah a konverze se soustředí do testované vrstvy.

Unixový čas zůstává výborným nástrojem pro body na časové ose. Problémy vznikají, když jej systém používá jako odpověď na všechny časové otázky. Nejdříve je nutné určit, zda data popisují okamžik, kalendář, dobu trvání nebo pořadí. Teprve potom lze zvolit číslo, formát a pravidla převodu.