Unix-tidsstämpel

Så fungerar det

Unix-tid är antalet sekunder sedan den 1 januari 1970 i UTC. Nollpunkten valdes för att den låg bekvämt nära när måttet infördes, inte för att den betyder något i sig.

Måttet räknar inte skottsekunder. En Unix-dag är alltid exakt 86 400 sekunder, även de dygn då UTC fick en sekund extra. Det gör räkningen enkel, och Unix-tiden följer ändå UTC:s datum och klockslag. Men skillnaden mellan två tidsstämplar är inte alltid den tid som verkligen gått. Sedan 1972 har 27 skottsekunder lagts in, och dem räknar Unix-tiden inte. För allt utom satellitnavigering saknar det betydelse.

Enheten gissas ur talets storlek. Ett tal under tio miljarder läses som sekunder, vilket räcker fram till år 2286, och större tal som millisekunder eller mikrosekunder. Gränsen ligger där för att ett årtal i närheten av i dag ska tolkas rätt.

Negativa tal går bakåt före 1970 och fungerar likadant.

En förtecknad trettiotvåbitars räknare tar slut den 19 januari 2038 klockan 03.14.07 UTC, varefter den slår runt till 1901. Det kallas år 2038-problemet och är samma sorts fel som år 2000-problemet, fast i binär form. System som räknar i 64 bitar berörs inte.

Ett datum utan tidszon i texten tolkas som UTC, så att samma text alltid ger samma tal oavsett var den läses.

Så tolkas talet

Mellanslag och understreck i talet tas bort innan det läses. Utan vald enhet avgör storleken: under 10 miljarder läses talet som sekunder, från 10 miljarder som millisekunder och från 100 biljoner som mikrosekunder. Gränserna gör att ett tal i millisekunder från före 26 april 1970 och ett i mikrosekunder från före 3 mars 1973 läses i fel enhet. Nanosekunder finns inte som enhet: 1 757 000 000 000 000 000 nanosekunder, som är 4 september 2025, läses som mikrosekunder och hamnar år 57647. Stryk då de tre sista siffrorna. Enligt ECMAScript-standarden räcker webbläsarens kalender 100 miljoner dygn åt vardera hållet från 1970, till 13 september år 275760, och tal utanför det ger felmeddelande.

Exempel: där 32 bitar tar slut

2³¹ − 1 = 2 147 483 647 är det största tal en förtecknad 32-bitars räknare rymmer. Sekunden efter blir en sådan räknare −2 147 483 648, som verktyget visar som 13 december 1901 kl. 20.45.52 UTC. Ögonblick utanför de två gränserna får en varning: 2 147 483 648 ger den, 2 147 483 647 inte.

Datum som text

I JavaScript tolkas 2026-09-12T14:30 som lokal tid men 2026-09-12 som UTC, enligt ECMAScript-standarden. Verktyget tolkar båda som UTC, så 2026-09-12T14:30 ger alltid 1 789 223 400. Bråkdelar av sekunder avrundas nedåt till hel sekund.

Datum som inte finns avvisas: 2026-02-30 ger ett felmeddelande, medan Date i V8, motorn i Chrome och Edge, gör det till 2 mars utan varning. 24:00 godtas som dygnets slut, som ECMAScript tillåter.

Skottsekunder och tiden före 1970

POSIX definierar sekunder sedan epoken med en formel och säger uttryckligen att förhållandet till den verkliga UTC-tiden är ospecificerat. ECMAScript säger att det inte finns något tidsvärde för ett ögonblick inne i en skottsekund. Därför ger 2016-12-31T23:59:60Z, den senaste skottsekunden, felmeddelandet att klockslaget inte finns, medan sekunden före ger 1 483 228 799 och midnatt efteråt 1 483 228 800. Enligt IERS var skillnaden mellan atomtiden TAI och UTC 10 sekunder 1972 och är 37 sekunder sedan 1 januari 2017. IERS Bulletin C 72 meddelar att ingen skottsekund läggs in i slutet av december 2026.

För negativa tal säger POSIX att förhållandet är odefinierat. Verktyget följer ECMAScript, som räknar bakåt med den gregorianska kalendern även före dess införande.

Källor

• 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 sedan 1972)

Så kontrolleras verktygen