Unix-tidsstempel

Slik fungerer det

Unix-tid er antallet sekunder siden 1. januar 1970 i UTC. Nullpunktet ble valgt fordi det lå beleilig nær da målet ble innført, ikke fordi det betyr noe i seg selv.

Målet teller ikke skuddsekunder. En Unix-dag er alltid nøyaktig 86 400 sekunder, også de døgnene da UTC fikk ett sekund ekstra. Det gjør regningen enkel, og Unix-tiden følger likevel datoene og klokkeslettene i UTC. Men forskjellen mellom to tidsstempler er ikke alltid den tiden som faktisk har gått. Siden 1972 er det lagt inn 27 skuddsekunder, og dem teller ikke Unix-tiden. For alt annet enn satellittnavigasjon spiller det ingen rolle.

Enheten gjettes ut fra tallets størrelse. Et tall under ti milliarder leses som sekunder, noe som rekker fram til år 2286, og større tall som millisekunder eller mikrosekunder. Grensen ligger der for at et årstall nær i dag skal tolkes riktig.

Negative tall går bakover før 1970 og fungerer likedan.

En fortegnet trettitobits teller tar slutt 19. januar 2038 klokka 03.14.07 UTC, hvoretter den slår rundt til 1901. Det kalles år 2038-problemet og er samme slags feil som år 2000-problemet, bare i binær form. Systemer som teller i 64 bit berøres ikke.

En dato uten tidssone i teksten tolkes som UTC, slik at samme tekst alltid gir samme tall uansett hvor den leses.

Slik tolkes tallet

Mellomrom og understreker i tallet fjernes før det leses. Uten valgt enhet avgjør størrelsen: under 10 milliarder leses tallet som sekunder, fra 10 milliarder som millisekunder og fra 100 billioner som mikrosekunder. Grensene gjør at et tall i millisekunder fra før 26. april 1970 og et i mikrosekunder fra før 3. mars 1973 leses i feil enhet. Nanosekunder finnes ikke som enhet: 1 757 000 000 000 000 000 nanosekunder, som er 4. september 2025, leses som mikrosekunder og havner i år 57647. Stryk da de tre siste sifrene. Etter ECMAScript-standarden rekker nettleserens kalender 100 millioner døgn i hver retning fra 1970, til 13. september år 275760, og tall utenfor det gir en feilmelding.

Eksempel: der 32 bit tar slutt

2³¹ − 1 = 2 147 483 647 er det største tallet en 32-biters teller med fortegn har plass til. Sekundet etter blir en slik teller −2 147 483 648, som verktøyet viser som 13. desember 1901 kl. 20.45.52 UTC. Øyeblikk utenfor de to grensene får en advarsel: 2 147 483 648 gir den, 2 147 483 647 ikke.

Datoer som tekst

I JavaScript tolkes 2026-09-12T14:30 som lokal tid, men 2026-09-12 som UTC, etter ECMAScript-standarden. Verktøyet tolker begge som UTC, så 2026-09-12T14:30 gir alltid 1 789 223 400. Brøkdeler av sekunder rundes ned til hele sekunder.

Datoer som ikke finnes, avvises: 2026-02-30 gir en feilmelding, mens Date i V8, motoren i Chrome og Edge, gjør den om til 2. mars uten varsel. 24:00 godtas som slutten av døgnet, slik ECMAScript tillater.

Skuddsekunder og tiden før 1970

POSIX definerer sekunder siden epoken med en formel og sier uttrykkelig at forholdet til den virkelige UTC-tiden er uspesifisert. ECMAScript sier at det ikke finnes noen tidsverdi for et øyeblikk inne i et skuddsekund. Derfor gir 2016-12-31T23:59:60Z, det hittil siste skuddsekundet, feilmeldingen om at klokkeslettet ikke finnes, mens sekundet før gir 1 483 228 799 og midnatt etterpå 1 483 228 800. Ifølge IERS var forskjellen mellom atomtiden TAI og UTC 10 sekunder i 1972 og har vært 37 sekunder siden 1. januar 2017. IERS Bulletin C 72 kunngjør at det ikke legges inn noe skuddsekund i slutten av desember 2026.

For negative tall sier POSIX at forholdet er udefinert. Verktøyet følger ECMAScript, som regner bakover med den gregorianske kalenderen også før den ble innfø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)

Slik kontrolleres verktøyene