Hvad er et Unix-tidsstempel?

Et Unix-tidsstempel er et enkelt tal: antallet af sekunder, der er forløbet siden Unix-epoken, defineret som 00:00:00 UTC den 1. januar 1970. Det er det. Ingen tidszone, ingen datostreng, ingen månedsnavne – bare et heltal, der tikker opad med én enhed i sekundet.

Fordi epoken er fast og universel, betyder et tidsstempel som 1700000000 det nøjagtige samme tidspunkt overalt på Jorden. En server i Tokyo og en bærbar i Chicago vil begge være enige om, at det refererer til 14. november 2023 kl. 22:13:20 UTC. Den lokale visning varierer efter tidszone, men det underliggende tal ændrer sig aldrig.

En bevidst forenkling: Unix-tid ignorerer skudsekunder. Den antager, at hver dag er præcis 86.400 sekunder lang, hvilket ikke helt passer med astronomisk virkelighed, men holder regnestykket rent. Mere om det nedenfor.

Hvorfor ingeniører elsker dem

Tidsstempler er overalt i software – filændringstider, databaseregistreringer, API-svar, JWT-udløbsfelter, loglinjer – og det er der god grund til:

• De er en enkelt værdi. Et heltal gemmer en fuld dato og et klokkeslæt. Ingen parsing, ingen tvetydighed om MM/DD versus DD/MM.
• De er tidszoneuafhængige. Tallet er altid UTC. Du konverterer til lokal tid, kun når du viser det til et menneske.
• De sammenlignes og sorteres trivielt. Hvilken begivenhed kom først? Det mindre heltal. Varighed mellem to begivenheder? Træk dem fra; svaret er i sekunder.
• De gemmes kompakt. Et enkelt 4- eller 8-byte heltal versus en formateret streng.

Derfor taler så meget infrastruktur i epok-sekunder under motorhjelmen, selv når grænsefladen viser dig en venlig 2026-07-23. Hvis du vil bevæge dig mellem de to repræsentationer, laver en Unix tidsstempel konverter oversættelsen i begge retninger.

At læse et: Et gennemarbejdet eksempel

Tag tidsstemplet 1000000000 – et berømt et, fordi det rullede over i live-tv blandt Unix-entusiaster.

For at læse det i hånden dividerer du sekunderne ned i større enheder. Groft sagt er 1.000.000.000 sekunder omkring 31,7 år (et år er ~31.556.952 sekunder). Læg det til 1970-epoken, og du lander i 2001. Det præcise øjeblik er 9. september 2001, 01:46:40 UTC.

Du udfører sjældent denne aritmetik manuelt – alle sprog har en indbygget funktion. I Python:

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

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

```

Hovedpointen: konvertering er altid forankret til UTC. Funktionen omdanner en rå optælling af sekunder til en kalenderdato ved at gå fremad fra epoken. Hvis du i stedet vil have lokal tid, anvender du en tidszoneforskydning efter UTC-konverteringen – selve tidsstemplet bærer ingen zoneinformation.

År 2038-problemet

Her bliver historien interessant – og hvor mange ellers velfungerende systemer har et tikkende ur indeni.

I årtier var C-standardtypen, der bruges til at holde Unix-tid, time_t, almindeligvis et signeret 32-bit heltal. Et signeret 32-bit heltal kan repræsentere værdier fra −2.147.483.648 op til 2.147.483.647. Den øvre grænse er problemet.

Tæller man sekunder fra 1970-epoken, nås værdien 2.147.483.647 03:14:07 UTC den 19. januar 2038. Et sekund senere skal tælleren blive 2.147.483.648 – men det tal passer ikke i et signeret 32-bit heltal. I stedet for at fortsætte opad overløber og vikles bitsene rundt til den mest negative værdi, −2.147.483.648.

Et negativt tidsstempel fortolkes som et tidspunkt før epoken. Så uret stopper ikke bare – det hopper bagud til 13. december 1901. Ethvert system, der stolede på sin 32-bit time_t, tror pludselig, det er det tidlige tyvende århundrede.

Dette kaldes ofte Y2K38-fejlen eller Unix-millenniumfejlen, og strukturelt er det den samme slags fastbredde-overløb, der drev år 2000-skrækken – bare længere ude og forankret i binære heltalsgrænser snarere end tocifrede år.

Hvor det faktisk bider

Moderne 64-bit stationære computere og servere blev stort set rettet for år siden. Risikoen koncentrerer sig på steder, der er svære at opdatere:

• Indlejrede og industrielle systemer. Routere, controllere, medicinsk udstyr, bil-ECU'er og IoT-hardware, der blev leveret med 32-bit time_t og kan køre uforstyrret i 20+ år. Mange enheder, der implementeres i dag, vil stadig være i drift i 2038.
• Legacy C-kode. Applikationer kompileret mod en gammel time_t-definition, især hvor typen sneg sig ind i diskformater eller netværksprotokoller.
• Gamle databaser og filsystemer. Lagringsformater, der pakkede tidsstempler ind i 32-bit felter. Nogle ældre systemer viser allerede symptomer, når de håndterer fremtidige datoer – tænk et 20-årigt realkreditlån eller en certifikatudløb, der når forbi 2038.

Fejltilstanden er ikke altid et dramatisk nedbrud. Nogle gange er det en subtil forkert beregnet dato: et udløbet token, der læses som gyldigt, en sorteringsrækkefølge, der vendes om, en planlagt opgave, der udløses i 1901.

Løsningen: 64-bit tid

Løsningen er ligetil i princippet – udvid time_t til 64 bit. Et signeret 64-bit heltal kan tælle sekunder langt ud over enhver praktisk horisont: overløbspunktet ligger cirka 292 milliarder år i fremtiden, behageligt forbi Solens forventede levetid.

De fleste nuværende operativsystemer har allerede foretaget dette skift. 64-bit Linux bruger en 64-bit time_t; selv 32-bit Linux fik 64-bit tidsunderstøttelse i kernen og glibc i de seneste år. Den svære del er ikke selve rettelsen – det er at finde og genopbygge hver eneste sidste firmware, hvert lagrede format og hver tredjeparts binær, der stadig antager 32 bit. Det revisionsarbejde er det virkelige 2038-projekt.

Hvordan skudsekunder passer ind

Astronomisk tid og atomtid driver lidt fra hinanden, så officiel UTC indsætter lejlighedsvis et skudsekund for at holde ure på linje med Jordens rotation. Unix-tid foregiver designmæssigt, at disse ikke eksisterer – den hardkoder 86.400 sekunder per dag.

Når et skudsekund forekommer, "smearer" systemer det typisk – spreder det ekstra sekund over et vindue (Google populariserede en 24-timers smear), så intet ur nogensinde skal vise det umulige 23:59:60. Resultatet: Unix-tidsstempler forbliver glatte og monotone, på bekostning af at være en lille brøkdel af et sekund ude fra streng UTC under en smear. For stort set al software er dette præcis det kompromis, du ønsker. 2038-overløbet er et heltalsbredde-problem; skudsekunder er en separat, meget mindre definitions-særhed – bland dem ikke sammen.

Vigtige pointer

• Et Unix-tidsstempel er sekunder siden 00:00:00 UTC den 1. januar 1970, skudsekunder ignoreret.
• Det er et enkelt, tidszoneuafhængigt heltal – nemt at gemme, sammenligne og sortere.
• Konvertering er altid relativ til UTC; lokal tid anvendes bagefter.
• Signeret 32-bit time_t overløber 03:14:07 UTC den 19. januar 2038, vikles til en negativ værdi og hopper til 1901.
• Løsningen er 64-bit time_t; indsatsen er at revidere indlejrede og legacy-systemer.

Vil du se det i aktion? Indsæt en hvilken som helst epok-værdi i Unix tidsstempel konverter for at læse den som en menneskelig dato – eller gå den anden vej og omdann en dato til dens tidsstempel.

Ofte stillede spørgsmål

Er et Unix-tidsstempel i sekunder eller millisekunder?

Klassisk Unix-tid er i sekunder. Dog bruger JavaScript og mange web-API'er millisekunder siden epoken, så en værdi som 1700000000000 er 1.000× større. Et hurtigt tip: et sekundbaseret tidsstempel for en nylig dato har 10 cifre; et millisekundbaseret har 13. Når du er i tvivl, så tjek størrelsesordenen før konvertering.

Vil år 2038-problemet crashe min telefon eller bærbare?

Næsten helt sikkert ikke. Moderne 64-bit operativsystemer bruger allerede en 64-bit time_t, hvilket skubber overløbet milliarder af år ud. Den reelle eksponering er i langlivede indlejrede enheder og gammel software, der stadig er afhængig af 32-bit tid og måske ikke opdateres før 2038.

Kan et Unix-tidsstempel være negativt?

Ja. Negative værdier repræsenterer tidspunkter før 1970-epoken – for eksempel er -1 31. december 1969, 23:59:59 UTC. Det er præcis, hvad et 32-bit overløb producerer i 2038, hvilket er grunden til, at uret ser ud til at hoppe tilbage til 1901.

Hvorfor ignorerer Unix-tid skudsekunder?

For at holde matematikken enkel og forudsigelig. At behandle hver dag som præcis 86.400 sekunder betyder, at varigheder blot er subtraktion, og tidsstempler forbliver monotone. Det lille misforhold med astronomisk UTC håndteres ved at "smeare" skudsekundet, hvilket næsten alle applikationer foretrækker frem for at håndtere en 23:59:60-kantcase.

Hvordan konverterer jeg et tidsstempel uden at skrive kode?

Brug et onlineværktøj. Unix tidsstempel konverter accepterer en epok-værdi og viser det matchende UTC- og lokale dato-klokkeslæt øjeblikkeligt, og det konverterer også kalenderdatoer tilbage til tidsstempler.