Hva er et Unix-tidsstempel?

Et Unix-tidsstempel er et enkelt tall: antall sekunder som har gått siden Unix-epoken, definert som 00:00:00 UTC 1. januar 1970. Det er alt. Ingen tidssone, ingen datostreng, ingen månedsnavn — bare et heltall som tikker oppover med én enhet per sekund.

Fordi epoken er fast og universell, betyr et tidsstempel som 1700000000 nøyaktig samme øyeblikk overalt på jorden. En server i Tokyo og en bærbar PC i Chicago vil begge være enige om at det refererer til 14. november 2023 kl. 22:13:20 UTC. Den lokale visningen varierer med tidssone, men det underliggende tallet gjør det aldri.

En bevisst forenkling: Unix-tid ignorerer skuddsekunder. Den antar at hver dag er nøyaktig 86 400 sekunder lang, noe som ikke er helt sant i astronomisk virkelighet, men som holder regnestykket rent. Mer om det nedenfor.

Hvorfor ingeniører elsker dem

Tidsstempler er overalt i programvare — filendringstider, databaseregistreringer, API-svar, JWT-utløpsfelt, logglinjer — og det er en god grunn:

De er en enkelt verdi. Ett heltall lagrer en full dato og tid. Ingen parsing, ingen tvetydighet om MM/DD versus DD/MM.
De er tidssoneuavhengige. Tallet er alltid UTC. Du konverterer til lokal tid bare når du viser det til et menneske.
De sammenlignes og sorteres enkelt. Hvilken hendelse kom først? Det minste heltallet. Varighet mellom to hendelser? Trekk dem fra; svaret er i sekunder.
De lagres kompakt. Et enkelt 4- eller 8-byte heltall versus en formatert streng.

Dette er grunnen til at så mye infrastruktur snakker i epoksekunder under panseret, selv når grensesnittet viser deg et vennlig 2026-07-23. Hvis du vil bevege deg mellom de to representasjonene, gjør en Unix tidsstempel omformer oversettelsen i begge retninger.

Å lese ett: Et praktisk eksempel

Ta tidsstempelet 1000000000 — et berømt et, fordi det rullet over på direktesendt TV blant Unix-entusiaster.

For å lese det for hånd, deler du sekundene ned i større enheter. Omtrent 1 000 000 000 sekunder er omtrent 31,7 år (et år er ~31 556 952 sekunder). Legg det til 1970-epoken, og du lander i 2001. Det nøyaktige øyeblikket er 9. september 2001, 01:46:40 UTC.

Du gjør sjelden denne aritmetikken manuelt — alle språk har en innebygd funksjon. I Python:

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

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

```

Hovedpoenget: konvertering er alltid forankret til UTC. Funksjonen gjør en rå telling av sekunder til en kalenderdato ved å gå fremover fra epoken. Hvis du vil ha lokal tid i stedet, bruker du en tidssoneforskyvning etter UTC-konverteringen — selve tidsstempelet bærer ingen soneinformasjon.

År 2038-problemet

Her blir historien interessant — og hvor mange ellers velfungerende systemer har en tikke klokke inni seg.

I flere tiår var C-standardtypen som ble brukt til å holde Unix-tid, time_t, vanligvis et signert 32-bits heltall. Et signert 32-bits heltall kan representere verdier fra −2 147 483 648 opp til 2 147 483 647. Den øvre grensen er problemet.

Når man teller sekunder fra 1970-epoken, nås verdien 2 147 483 647 03:14:07 UTC 19. januar 2038. Ett sekund senere må telleren bli 2 147 483 648 — men det tallet får ikke plass i et signert 32-bits heltall. I stedet for å fortsette oppover, flyter bitene over og vikler seg rundt til den mest negative verdien, −2 147 483 648.

Et negativt tidsstempel tolkes som et tidspunkt før epoken. Så klokken stopper ikke bare — den hopper bakover til 13. desember 1901. Ethvert system som stolte på sin 32-bits time_t, tror plutselig at det er tidlig på 1900-tallet.

Dette kalles ofte Y2K38-buggen eller Unix-millenniumsbuggen, og strukturelt er det den samme typen fastbreddeoverflyt som drev år 2000-skrekken — bare lenger fremme og forankret i binære heltallsgrenser i stedet for tosifrede år.

Hvor det faktisk biter

Moderne 64-bits stasjonære datamaskiner og servere ble stort sett fikset for år siden. Risikoen er konsentrert på steder som er vanskelige å oppdatere:

Innebygde og industrielle systemer. Rutere, kontrollere, medisinske enheter, bil-ECU-er og IoT-maskinvare som ble levert med 32-bits time_t og kan kjøre uforstyrret i 20+ år. Mange enheter som distribueres i dag, vil fortsatt være i bruk i 2038.
Eldre C-kode. Applikasjoner kompilert mot en gammel time_t-definisjon, spesielt der typen snek seg inn i diskformater eller nettverksprotokoller.
Gamle databaser og filsystemer. Lagringsformater som pakket tidsstempler inn i 32-bits felt. Noen eldre systemer viser allerede symptomer når de håndterer datoer langt frem i tid — tenk et 20-års boliglån eller en sertifikatutløp som når forbi 2038.

Feilmodusen er ikke alltid et dramatisk krasj. Noen ganger er det en subtil dato som er regnet feil: et utløpt token som leses som gyldig, en sorteringsrekkefølge som inverteres, en planlagt jobb som utløses i 1901.

Løsningen: 64-bits tid

Løsningen er enkel i prinsippet — utvid time_t til 64 bits. Et signert 64-bits heltall kan telle sekunder langt utover enhver praktisk horisont: overflytpunktet ligger omtrent 292 milliarder år inn i fremtiden, komfortabelt forbi solens forventede levetid.

De fleste nåværende operativsystemer har allerede gjort dette trekket. 64-bits Linux bruker en 64-bits time_t; selv 32-bits Linux fikk 64-bits tidsstøtte i kjernen og glibc de siste årene. Den vanskelige delen er ikke selve løsningen — det er å finne og bygge om hver eneste bit av fastvare, hvert lagrede format og hver tredjeparts binær som fortsatt antar 32 bits. Det revisjonsarbeidet er det virkelige 2038-prosjektet.

Hvordan skuddsekunder passer inn

Astronomisk tid og atomtid driver litt fra hverandre, så offisiell UTC setter inn en skuddsekund av og til for å holde klokkene på linje med jordens rotasjon. Unix-tid, ved design, later som om disse ikke eksisterer — den hardkoder 86 400 sekunder per dag.

Når et skuddsekund oppstår, "smører" systemer det vanligvis — de sprer det ekstra sekundet over et tidsvindu (Google populariserte en 24-timers smøring) slik at ingen klokke noen gang må vise det umulige 23:59:60. Resultatet: Unix-tidsstempler forblir jevne og monotone, på bekostning av å være en liten brøkdel av et sekund unna streng UTC under en smøring. For praktisk talt all programvare er dette akkurat det kompromisset du ønsker. 2038-overflyten er et heltallsbredde-problem; skuddsekunder er en separat, mye mindre definisjons-særhet — ikke bland dem sammen.

Hovedpunkter

Et Unix-tidsstempel er sekunder siden 00:00:00 UTC 1. januar 1970, skuddsekunder ignorert.
Det er et enkelt, tidssoneuavhengig heltall — enkelt å lagre, sammenligne og sortere.
Konvertering er alltid relativ til UTC; lokal tid brukes etterpå.
Signert 32-bits time_t flyter over 03:14:07 UTC 19. januar 2038, vikler seg til en negativ verdi og hopper til 1901.
Løsningen er 64-bits time_t; innsatsen er å revidere innebygde og eldre systemer.

Vil du se det i aksjon? Lim inn en hvilken som helst epokeverdi i Unix tidsstempel omformer for å lese den som en menneskelig dato — eller gå den andre veien og gjør en dato om til tidsstempelet.

Ofte stilte spørsmål

Er et Unix-tidsstempel i sekunder eller millisekunder?

Klassisk Unix-tid er i sekunder. Imidlertid bruker JavaScript og mange web-API-er millisekunder siden epoken, så en verdi som 1700000000000 er 1000× større. Et raskt tegn: et sekundbasert tidsstempel for en nylig dato har 10 sifre; et millisekundbasert har 13. Når du er i tvil, sjekk størrelsesorden før du konverterer.

Vil år 2038-problemet krasje telefonen eller den bærbare datamaskinen min?

Nesten helt sikkert ikke. Moderne 64-bits operativsystemer bruker allerede en 64-bits time_t, som skyver overflyten milliarder av år ut. Den virkelige eksponeringen er i langlivede innebygde enheter og gammel programvare som fortsatt er avhengig av 32-bits tid og kanskje ikke blir oppdatert før 2038.

Kan et Unix-tidsstempel være negativt?

Ja. Negative verdier representerer øyeblikk før 1970-epoken — for eksempel er -1 31. desember 1969, 23:59:59 UTC. Dette er nøyaktig hva en 32-bits overflyt produserer i 2038, og det er derfor klokken ser ut til å hoppe tilbake til 1901.

Hvorfor ignorerer Unix-tid skuddsekunder?

For å holde matematikken enkel og forutsigbar. Å behandle hver dag som nøyaktig 86 400 sekunder betyr at varigheter bare er subtraksjon, og tidsstempler forblir monotone. Det lille avviket med astronomisk UTC håndteres ved å "smøre" skuddsekundet, noe nesten alle applikasjoner foretrekker fremfor å håndtere en 23:59:60-kantsak.

Hvordan konverterer jeg et tidsstempel uten å skrive kode?

Bruk et nettbasert verktøy. Unix tidsstempel omformer godtar en epokeverdi og viser den tilsvarende UTC- og lokale dato-klokkeslett umiddelbart, og den konverterer også kalenderdatoer tilbake til tidsstempler.