Vad är en Unix-tidsstämpel?

En Unix-tidsstämpel är ett enda tal: antalet sekunder som har förflutit sedan Unix-epoken, definierad som 00:00:00 UTC den 1 januari 1970. Det är allt. Ingen tidszon, ingen datumsträng, inga månadsnamn – bara ett heltal som tickar uppåt med en enhet per sekund.

Eftersom epoken är fast och universell betyder en tidsstämpel som 1700000000 exakt samma ögonblick överallt på jorden. En server i Tokyo och en bärbar dator i Chicago kommer båda överens om att den avser 14 november 2023 klockan 22:13:20 UTC. Den lokala visningen skiljer sig åt beroende på tidszon, men det underliggande talet gör det aldrig.

En medveten förenkling: Unix-tid ignorerar skottsekunder. Den antar att varje dag är exakt 86 400 sekunder lång, vilket inte är helt sant i astronomisk verklighet men håller aritmetiken ren. Mer om det nedan.

Varför ingenjörer älskar dem

Tidsstämplar finns överallt i mjukvara – filändringstider, databasposter, API-svar, JWT-förfallofält, loggrader – och av goda skäl:

• De är ett enda värde. Ett heltal lagrar ett fullt datum och en full tid. Ingen tolkning, ingen tvetydighet om MM/DD kontra DD/MM.
• De är tidszonsagnostiska. Talet är alltid UTC. Du konverterar till lokal tid först när du visar det för en människa.
• De jämför och sorterar trivialt. Vilken händelse kom först? Det mindre heltalet. Tidsskillnad mellan två händelser? Subtrahera dem; svaret är i sekunder.
• De lagras kompakt. Ett enda 4- eller 8-byte heltal jämfört med en formaterad sträng.

Det är därför så mycket infrastruktur talar i epoksekunder under huven, även när gränssnittet visar dig ett vänligt 2026-07-23. Om du vill röra dig mellan de två representationerna gör en Unix-tidsstämpelomvandlare översättningen i båda riktningarna.

Läsa en: Ett arbetat exempel

Ta tidsstämpeln 1000000000 – en berömd sådan, eftersom den rullade över i direktsänd tv bland Unix-entusiaster.

För att läsa den för hand delar du upp sekunderna i större enheter. Grovt räknat är 1 000 000 000 sekunder ungefär 31,7 år (ett år är ~31 556 952 sekunder). Lägg till det till 1970-epoken och du hamnar i 2001. Det exakta ögonblicket är 09 september 2001, 01:46:40 UTC.

Du gör sällan denna aritmetik manuellt – varje språk har en inbyggd funktion. I Python:

```python from datetime import datetime, timezone datetime.fromtimestamp(1000000000, tz=timezone.utc)

2001-09-09 01:46:40+00:00

```

Huvudpoängen: konvertering är alltid förankrad i UTC. Funktionen omvandlar en rå räkning av sekunder till ett kalenderdatum genom att gå framåt från epoken. Om du istället vill ha lokal tid tillämpar du en tidszonsförskjutning efter UTC-konverteringen – tidsstämpeln i sig bär ingen zoninformation.

År 2038-problemet

Här blir historien intressant – och där många annars välbyggda system har en tickande klocka inuti sig.

I decennier var C-standardtypen som användes för att lagra Unix-tid, time_t, vanligtvis ett signerat 32-bitars heltal. Ett signerat 32-bitars heltal kan representera värden från −2 147 483 648 upp till 2 147 483 647. Den övre gränsen är problemet.

Räknar man sekunder från 1970-epoken nås värdet 2 147 483 647 klockan 03:14:07 UTC den 19 januari 2038. En sekund senare måste räknaren bli 2 147 483 648 – men det talet får inte plats i ett signerat 32-bitars heltal. Istället för att fortsätta uppåt svämmar bitarna över och slår runt till det mest negativa värdet, −2 147 483 648.

En negativ tidsstämpel tolkas som en tid före epoken. Så klockan stannar inte bara – den hoppar bakåt till 13 december 1901. Alla system som litade på sin 32-bitars time_t tror plötsligt att det är tidigt 1900-tal.

Detta kallas ofta Y2K38-buggen eller Unix Millennium-buggen, och strukturellt är det samma typ av fixbreddsöversvämning som drev år 2000-skräcken – bara längre fram och rotad i binära heltalsgränser snarare än tvåsiffriga år.

Var det faktiskt biter

Moderna 64-bitars stationära datorer och servrar åtgärdades till stor del för år sedan. Risken koncentreras till platser som är svåra att uppdatera:

• Inbyggda och industriella system. Routrar, styrenheter, medicintekniska produkter, fordons-ECU:er och IoT-hårdvara som levererades med 32-bitars time_t och kan köras orörda i 20+ år. Många enheter som distribueras idag kommer fortfarande att vara i drift 2038.
• Äldre C-kod. Applikationer kompilerade mot en gammal time_t-definition, särskilt där typen smugit sig in i diskformat eller nätverksprotokoll.
• Gamla databaser och filsystem. Lagringsformat som packade tidsstämplar i 32-bitars fält. Vissa äldre system visar redan symptom vid hantering av framtida datum – tänk ett 20-årigt bolån eller ett certifikat som löper ut efter 2038.

Felfallet är inte alltid en dramatisk krasch. Ibland är det ett subtilt felberäknat datum: en utgången token som läses som giltig, en sorteringsordning som inverteras, ett schemalagt jobb som utlöses 1901.

Fixen: 64-bitars tid

Botemedlet är enkelt i princip – bredda time_t till 64 bitar. Ett signerat 64-bitars heltal kan räkna sekunder långt bortom varje praktisk horisont: översvämningspunkten ligger ungefär 292 miljarder år i framtiden, bekvämt förbi solens förväntade livslängd.

De flesta nuvarande operativsystem har redan gjort detta drag. 64-bitars Linux använder en 64-bitars time_t; även 32-bitars Linux fick 64-bitars tidsstöd i kärnan och glibc under senare år. Det svåra är inte själva fixen – det är att hitta och bygga om varenda bit firmware, vartenda lagrat format och varje tredjepartsbinär som fortfarande antar 32 bitar. Det granskningsarbetet är det verkliga 2038-projektet.

Hur skottsekunder passar in

Astronomisk tid och atomtid driver isär något, så officiell UTC infogar ibland en skottsekund för att hålla klockor i linje med jordens rotation. Unix-tid, avsiktligt, låtsas att dessa inte finns – den hårdkodar 86 400 sekunder per dag.

När en skottsekund inträffar "smetar" system vanligtvis ut den – sprider den extra sekunden över ett fönster (Google populariserade en 24-timmars smetning) så att ingen klocka någonsin måste visa den omöjliga 23:59:60. Resultatet: Unix-tidsstämplar förblir jämna och monotona, till priset av att vara en liten bråkdel av en sekund fel från strikt UTC under en smetning. För praktiskt taget all mjukvara är detta exakt den avvägning du vill ha. 2038-översvämningen är ett heltalsbreddsproblem; skottsekunder är en separat, mycket mindre definitionsmärklighet – blanda inte ihop dem.

Viktiga slutsatser

• En Unix-tidsstämpel är sekunder sedan 00:00:00 UTC den 1 januari 1970, skottsekunder ignorerade.
• Det är ett enda, tidszonsagnostiskt heltal – enkelt att lagra, jämföra och sortera.
• Konvertering är alltid relativ till UTC; lokal tid tillämpas efteråt.
• Signerad 32-bitars time_t svämmar över klockan 03:14:07 UTC den 19 januari 2038, slår runt till ett negativt värde och hoppar till 1901.
• Fixen är 64-bitars time_t; ansträngningen är att granska inbyggda och äldre system.

Vill du se det i aktion? Klistra in ett epokvärde i Unix-tidsstämpelomvandlare för att läsa det som ett mänskligt datum – eller gå åt andra hållet och omvandla ett datum till dess tidsstämpel.

Vanliga frågor

Är en Unix-tidsstämpel i sekunder eller millisekunder?

Klassisk Unix-tid är i sekunder. Men JavaScript och många webb-API:er använder millisekunder sedan epoken, så ett värde som 1700000000000 är 1 000× större. En snabb ledtråd: en sekundbaserad tidsstämpel för ett nyligt datum har 10 siffror; en millisekundbaserad har 13. När du är osäker, kontrollera storleksordningen innan du konverterar.

Kommer år 2038-problemet att krascha min telefon eller bärbara dator?

Nästan säkert inte. Moderna 64-bitars operativsystem använder redan en 64-bitars time_t, vilket skjuter översvämningen miljarder år framåt. Den verkliga exponeringen finns i långlivade inbyggda enheter och gammal mjukvara som fortfarande förlitar sig på 32-bitars tid och kanske inte uppdateras före 2038.

Kan en Unix-tidsstämpel vara negativ?

Ja. Negativa värden representerar ögonblick före 1970-epoken – till exempel är -1 den 31 december 1969, 23:59:59 UTC. Detta är exakt vad en 32-bitars översvämning producerar 2038, vilket är anledningen till att klockan verkar hoppa tillbaka till 1901.

Varför ignorerar Unix-tid skottsekunder?

För att hålla matematiken enkel och förutsägbar. Att behandla varje dag som exakt 86 400 sekunder innebär att tidsintervall bara är subtraktion, och tidsstämplar förblir monotona. Den lilla avvikelsen från astronomisk UTC hanteras genom att "smeta ut" skottsekunden, vilket nästan alla applikationer föredrar framför att hantera ett 23:59:60-kantfall.

Hur konverterar jag en tidsstämpel utan att skriva kod?

Använd ett onlineverktyg. Unix-tidsstämpelomvandlare accepterar ett epokvärde och visar omedelbart matchande UTC och lokal datum-tid, och konverterar också kalenderdatum tillbaka till tidsstämplar.