Unix-tidsstempel

Sådan virker det

Unix-tid er antallet af sekunder siden 1. januar 1970 i UTC. Nulpunktet blev valgt, fordi det lå bekvemt tæt på, da målet blev indført, ikke fordi det betyder noget i sig selv.

Målet tæller ikke skudsekunder. En Unix-dag er altid præcis 86.400 sekunder, også de døgn hvor UTC fik et sekund ekstra. Det gør regningen enkel, og Unix-tid følger stadig datoer og klokkeslæt i UTC. Men forskellen mellem to tidsstempler er ikke altid den tid, der faktisk er gået. Siden 1972 er der indsat 27 skudsekunder, som Unix-tid ikke tæller med. For alt andet end satellitnavigation er det uden betydning.

Enheden gættes ud fra tallets størrelse. Et tal under ti milliarder læses som sekunder, hvilket rækker frem til år 2286, og større tal som millisekunder eller mikrosekunder. Grænsen ligger der, for at et årstal tæt på i dag skal læses rigtigt.

Negative tal går tilbage før 1970 og fungerer på samme måde.

En fortegnet 32-bits tæller slipper op den 19. januar 2038 klokken 3.14.07 UTC, hvorefter den slår om til 1901. Det kaldes år 2038-problemet og er samme slags fejl som år 2000-problemet, bare i binær form. Systemer, der tæller i 64 bit, berøres ikke.

En dato uden tidszone i teksten læses som UTC, så den samme tekst altid giver det samme tal, uanset hvor den læses.

Sådan læses tallet

Mellemrum og understreger i tallet fjernes, før det læses. Uden valgt enhed afgør størrelsen: under 10 milliarder læses tallet som sekunder, fra 10 milliarder som millisekunder og fra 100 billioner som mikrosekunder. Grænserne betyder, at et tal i millisekunder fra før den 26. april 1970 og et i mikrosekunder fra før den 3. marts 1973 læses i forkert enhed. Nanosekunder findes ikke som enhed: 1.757.000.000.000.000.000 nanosekunder, som er den 4. september 2025, læses som mikrosekunder og havner i år 57647. Stryg så de tre sidste cifre. Ifølge ECMAScript-standarden rækker browserens kalender 100 millioner døgn til hver side af 1970, til den 13. september år 275760, og tal uden for det giver en fejlmeddelelse.

Eksempel: hvor 32 bit slipper op

2³¹ − 1 = 2.147.483.647 er det største tal, en fortegnet 32-bits tæller kan rumme. Sekundet efter bliver sådan en tæller −2.147.483.648, som værktøjet viser som den 13. december 1901 kl. 20.45.52 UTC. Øjeblikke uden for de to grænser får en advarsel: 2.147.483.648 giver den, 2.147.483.647 ikke.

Datoer som tekst

I JavaScript læses 2026-09-12T14:30 som lokal tid, men 2026-09-12 som UTC, efter ECMAScript-standarden. Værktøjet læser begge som UTC, så 2026-09-12T14:30 giver altid 1.789.223.400. Brøkdele af sekunder rundes ned til hele sekunder.

Datoer, der ikke findes, afvises: 2026-02-30 giver en fejlmeddelelse, mens Date i V8, motoren i Chrome og Edge, gør den til 2. marts uden advarsel. 24:00 godtages som døgnets slutning, som ECMAScript tillader.

Skudsekunder og tiden før 1970

POSIX definerer sekunder siden epoken med en formel og siger udtrykkeligt, at forholdet til den virkelige UTC-tid er uspecificeret. ECMAScript siger, at der ikke findes nogen tidsværdi for et øjeblik inde i et skudsekund. Derfor giver 2016-12-31T23:59:60Z, det seneste skudsekund, fejlmeddelelsen om, at klokkeslættet ikke findes, mens sekundet før giver 1.483.228.799 og midnat bagefter 1.483.228.800. Ifølge IERS var forskellen mellem atomtiden TAI og UTC 10 sekunder i 1972 og er 37 sekunder siden 1. januar 2017. IERS’ Bulletin C 72 meddeler, at der ikke indsættes noget skudsekund i slutningen af december 2026.

For negative tal siger POSIX, at forholdet er udefineret. Værktøjet følger ECMAScript, som regner baglæns med den gregorianske kalender, også før den blev indført.

Kilder

• POSIX.1-2024 (The Open Group) – 4.19 Seconds Since the Epoch
• ECMAScript Language Specification – Time Values and Time Range
• IERS – Bulletin C
• IERS – Leap_Second.dat (TAI–UTC siden 1972)

Sådan kontrolleres værktøjerne