Unix-tidsstempel og År 2038-problemet forklart

Den 19. januar 2038, klokken 03:14:07 UTC, vil et stort antall datasystemer oppleve det som effektivt er en datumoverflow — Unix-tidsstempelets ekvivalent til Y2K.

Årsaken er verken mystisk eller komplisert. Det kommer ned til en beslutning tatt i de tidlige dagene av Unix: å lagre gjeldende tid som et 32-bits heltall. Det var et rimelig valg i 1970. I 2038 går det tom for plass.

For å sjekke hva en tidsstempelverdi representerer akkurat nå, konverterer Unix Timestamp Converter hvilket som helst tidsstempel — inkludert det problematiske 2.147.483.647 — til en lesbar dato øyeblikkelig.

Hvordan Unix-tidsstempel fungerer

Et Unix-tidsstempel er antallet sekunder som har gått siden 1. januar 1970, klokken 00:00:00 UTC. Dette startpunktet kalles Unix-epoken.

Akkurat nå er tidsstemplet et sted rundt 1.712.000.000 — et 10-sifret tall som vokser med ett hver sekund.

Tidsstemplet brukes overalt innen databehandling: serverlogger, API-svar, databaseposter, autentiseringstokener, filsystemmetadata og operativsystemets internals. Det er et praktisk format fordi ett enkelt heltall representerer et presist tidspunkt, er enkelt å sammenligne og sortere, og er tidssone-uavhengig.

Hva et 32-bits heltall kan inneholde

Et signert 32-bits heltall kan inneholde verdier fra −2.147.483.648 til 2.147.483.647.

Da Unix ble utviklet, ble tidsstempel lagret som signerte 32-bits heltall. Maksimumsverdien — 2.147.483.647 — tilsvarer 03:14:07 UTC den 19. januar 2038.

Ett sekund senere overflower telleren. Et signert 32-bits heltall kan ikke inneholde 2.147.483.648, så det svinger rundt til den største negative verdien: −2.147.483.648. Når det tolkes som et Unix-tidsstempel, representerer det negative tallet 20:45:52 UTC den 13. desember 1901.

Praktisk effekt: ethvert system som lagrer tidsstempel som et signert 32-bits heltall og ikke håndterer denne overflowen, vil plutselig representere datoer i 1901 når 2038 kommer.

Hvorfor Y2K er en nyttig sammenligning

De fleste har hørt om Y2K — bekymringen for at datasystemer som lagret år som to siffer (99 for 1999) ville feile når de rullover til 00, som kunne tolkes som 1900 i stedet for 2000.

År 2038-problemet er strukturelt likt:

  • Begge er forårsaket av et lagringsformat som virket tilstrekkelig når det ble valgt
  • Begge manifesterer seg bare på en spesifikk datoterskel
  • Begge påvirker mange systemer samtidig
  • Begge er løsbare, men krever bevisst migreringsarbeid

Hovedforskjellen er skala. Y2K påvirket hovedsakelig datostrengetter og to-sifret årsfelter i applikasjoner. 2038-problemet påvirker en fundamental datatype (32-bits heltall) brukt på operativsystemnivå på utallige plattformer.

Hvilke systemer er faktisk utsatt

Ikke utsatt:

  • Moderne 64-bits operativsystemer (Linux, macOS, Windows på 64-bits maskinvare) — de bruker 64-bits tidsrepresentasjoner
  • De fleste moderne applikasjoner bygget på 64-bits plattformer
  • Nye systemer bygget etter 2000 som brukte 64-bits heltall fra starten

Potensielt utsatt:

  • Innebygde systemer som kjører på 32-bits prosessorer — disse er utbredt i industrielt utstyr, medisinske enheter, bilsystemer, nettverksmaskinvare og forbrukerelektronikk
  • Eldre programvare kompilert for 32-bits systemer som lagrer tidsstempel som time_t og aldri ble oppdatert
  • Gamle databaser der tidsstempelkolonner ble definert som 32-bits heltall
  • Filsystemer som lagrer filandringsklokkeslettdatoer som 32-bits verdier (ext3 på Linux har for eksempel denne begrensningen)
  • Noen nettverksprotokoller som koder tidsstempel i 32-bits felt

Kategorien innebygde systemer er spesielt bekymringsfull fordi disse enhetene ofte har lange driftslevetider, kjører nedstrippet operativsystemer uten automatiske oppdateringer, og kan ikke være økonomisk levedyktig å erstatte eller oppdatere.

Implikasjoner i den virkelige verden

Industrielle systemer og infrastruktur

Kontrollsystemer for kraftnett, vannbehandling, produksjon og bygledelse kjører ofte på innebygd maskinvare med driftslevetider på flere tiår. En programmerbar logisk styring (PLC) installert i 2005 som kjører på 32-bits fastvare kan fortsatt være operativ i 2038 — og kan oppføre seg uventet når tidsstemplet overflower.

Finansielle systemer

Bank- og handelssystemer kjører ofte eldre programvare på stormaskiner eller eldre 32-bits plattformer. Ethvert system som lagrer transaksjonstidsstempel som 32-bits heltall kan produsere feilaktige tidsstempel eller avvise transaksjoner med datoer beregnet forbi overflowen.

IoT-enheter

Utbredelsen av billige, strømsparende mikrokontrollere i IoT-enheter betyr at millioner av enheter med 32-bits tidsrepresentasjoner blir distribuert og vil forbli i bruk etter 2038. Forbrukerutere, smarthjemsenheter, industrisensorer — mange kjører 32-bits Linux-kjerner eller bare-metal-fastvare uten noen 2038-mitigering.

Filsystemer

Filmetadata — opprettelsestid, endringsklokkeslettdato, tilgangstid — lagres av operativsystemet. På systemer som bruker 32-bits tidsfelt for disse metadataene, kan filer se ut til å ha endringsdatoer i 1901 etter overflowen. Dette ville ødelegge sikkerhetskopieringsprogramvare, versjonskontrollsystemer og alt som bruker filendringsklokkeslettdato for sammenligninger.

Hva som skjer med 64-bits systemer

Et signert 64-bits heltall kan inneholde verdier opp til 9.223.372.036.854.775.807.

Som et Unix-tidsstempel representerer den maksimale verdien året 292.277.026.596. Det er ingen praktisk bekymring om at 64-bits systemer skal gå tom for tidsstempelplassen — universet vil ha endt lenge før det tallet nås.

De fleste moderne operativsystemer migrerte til 64-bits tidsrepresentasjoner vel før 2038:

  • Linux på 64-bits maskinvare har brukt 64-bits time_t siden tidlig 2000-tall
  • Linux på 32-bits maskinvare løste problemet i kjerneversjonen 5.6 (utgitt i 2020), som bruker et 64-bits tidgrensesnitt på 32-bits systemer
  • macOS gikk over til 64-bits tid i OS X 10.6 (2009)
  • Windows bruker 64-bits FILETIME-strukturer, som er sikre forbi året 30.000

Den gjenstående risikoen ligger i systemer som eksplisitt lagrer tidsstempel i 32-bits heltallskolonner i databaser, eller i nettverksprotokollfelter definert som 32-bits, i stedet for å stole på operativsystemets time_t-type.

Løsningen

Løsningen er konseptuelt enkel: erstatt 32-bits tidsstempellagring med 64-bits. I praksis krever dette:

1. Oppdatering av datatypene som brukes til å lagre tidsstempel i kode (int32_t eller time_t på 32-bits → int64_t eller time_t på 64-bits) 2. Migrering av databasekolonner fra 32-bits heltall eller TIMESTAMP-felt (som ofte er 32-bits i eldre MySQL og lignende systemer) til 64-bits alternativer 3. Oppdatering av nettverksprotokollimplementeringer der 32-bits tidsstempelfelter er del av protokollspesifikasjonen 4. Omkompilering eller erstatning av fastvare på innebygde enheter

For programvare som kjører på 64-bits plattformer, er løsningen ofte en omkompilering med en 64-bits time_t. For innebygde systemer på 32-bits maskinvare kan det kreve maskinvareerstatning.

Innsatsen som kreves varierer enormt. En godt vedlikeholdt webapplikasjon som kjører på moderne infrastruktur trenger sannsynligvis minimale endringer. Et eldre industrielt kontrollsystem med tilpasset fastvare og uten aktivt utviklingsteam er et mye vanskeligere problem.

Hvor lang tid har vi igjen?

På skrivtidspunktet (april 2026) er det omtrent 12 år til 19. januar 2038.

Det høres ut som nok tid. For aktivt vedlikeholdt programvare er det sannsynligvis det — endringene er godt forstått og kan planlegges og gjennomføres systematisk.

For den lange halen av forlatt programvare, uvedlikeholdt innebygde enheter og eldre infrastruktur som kjører på 32-bits maskinvare, er 12 år ikke like komfortabelt. Enhetene som er vanskeligst å oppdatere er også de som mest sannsynlig fortsatt kjører i 2038.

Organisasjonene som bør være mest bekymret er de som kjører 32-bits innebygde systemer i kritisk infrastruktur — og det er nøyaktig de organisasjonene som er minst sannsynlige til å ha budsjett og institusjonell kunnskap til å håndtere det proaktivt.

År 2038-problemet vil ikke få fly til å falle ut av himmelen den 19. januar 2038. Men noen systemer vil oppføre seg feilaktig, noen logger vil vise meningsløse tidsstempel, og noen enheter vil trenge emergensoppmerksomhet. Jo nærmere du er kritisk infrastruktur på 32-bits maskinvare, desto mer er det verdt å sjekke nå i stedet for senere.