Forstå tidssoner, UTC og Unix-tidsstempler

Tid virker enkelt helt til du prøver å skrive programvare som håndterer det korrekt. Et møte planlagt til «kl. 15» betyr forskjellige ting i Tokyo, London og New York. Sommertid flytter klokkene fremover eller bakover — men ikke overalt, og ikke på de samme datoene. Et tidsstempel som ser korrekt ut i ditt lokale miljø feiler i produksjon fordi serveren er i en annen sone.

Tidssoner er et av de mest pålitelig forvirrende temaene innen programvareutvikling. Denne artikkelen forklarer hvordan de fungerer, hvor kompleksiteten kommer fra, og hvordan du unngår de vanligste feilene.

Hvorfor tidssoner finnes

Jorden roterer 360 grader på 24 timer, noe som betyr at solen er på sitt høyeste punkt på forskjellige tidspunkter avhengig av din lengdegrad. Før det 19. århundre stilte hver by klokkene sine etter lokal soltid — midt på dagen var når solen stod høyest. Det fungerte fint helt til jernbaner forbandt fjerne byer og en togtabell trengte en enkel, konsistent klokke.

I 1884 møttes delegater fra 25 nasjoner ved Den internasjonale meridiankonferansen i Washington, D.C. og ble enige om å dele verden inn i 24 standard tidssoner, hver forskjøvet fra nullmeridianen (0 graders lengdegrad) gjennom Greenwich, England.

I praksis følger tidssonegrenser politiske grenser, ikke pene lengdegradslinjer. Kina spenner over fem geografiske soner, men bruker en enkelt offisiell tid (UTC+8). India bruker UTC+5:30 — en halvtimesforskyvning. Nepal bruker UTC+5:45. Det virkelige kartet over tidssoner er rotete.

UTC vs. GMT

GMT (Greenwich Mean Time) er den gjennomsnittlige soltiden ved Royal Observatory i Greenwich. Det var verdens tidsreferanse i over et århundre.

UTC (Coordinated Universal Time) erstattet GMT som den internasjonale standarden i 1972. UTC er basert på atomklokker fremfor astronomisk observasjon, noe som gjør det langt mer presist. For de fleste praktiske formål viser UTC og GMT samme tid, men UTC er den korrekte tekniske referansen.

Sommertid: organisert kaos

Omtrent 70 land observerer sommertid (DST), og flytter klokkene en time fremover om våren og en time tilbake om høsten. Hensikten er å tilpasse våkne timer med dagslyset. Resultatet er en halvårlig kilde til feil.

Viktige komplikasjoner:

• Ikke universell. Mesteparten av Afrika, Asia og Sør-Amerika observerer ikke sommertid. I USA velger Arizona og Hawaii det bort.
• Forskjellige datoer. EU bytter den siste søndagen i mars og oktober. USA bytter den andre søndagen i mars og den første søndagen i november. De er ute av synk i flere uker hvert år.
• Tvetydige tidspunkter. Når klokkene stilles tilbake, forekommer timen fra kl. 01:00 til 02:00 to ganger. Et tidsstempel på «01:30» den dagen er tvetydig.
• Hoppede tidspunkter. Når klokkene stilles fremover, eksisterer ikke timen fra kl. 02:00 til 03:00. Et møte planlagt kl. 02:30 den dagen skjer aldri.
• Politiske endringer. Regjeringer kan (og gjør) endre sommertidsregler med kort varsel. Russland innførte permanent sommertid i 2011, byttet deretter til permanent normaltid i 2014. Marokko har endret sommertidsregler flere ganger.

ISO 8601: det universelle datoformatet

For å unngå tvetydighet definerer den internasjonale standarden ISO 8601 et klart dato- og tidsformat:

2026-03-29T14:30:00Z
2026-03-29T14:30:00+02:00
2026-03-29T14:30:00-05:00

• T skiller dato fra tid.
• Z betyr UTC («Zulu»-tidssonen i militær terminologi).
• +02:00 eller -05:00 er UTC-forskyvningen.

Dette formatet er entydig, sorterbart som ren tekst og universelt forstått av datoparsing-biblioteker. Når du er i tvil, bruk ISO 8601.

Unix-tidsstempler

Et Unix-tidsstempel (også kalt epoch-tid eller POSIX-tid) er antall sekunder som har gått siden 1. januar 1970, 00:00:00 UTC — et øyeblikk kjent som Unix-epoken.

Unix-tidsstempler har ingen tidssone — de er alltid i UTC. Det gjør dem ideelle for å lagre og sammenligne tider i programvare. Du konverterer til en lokal tidssone kun i presentasjonslaget.

IANA-tidssonedatabasen

Programvare trenger ikke bare UTC-forskyvninger — den trenger å kjenne den fullstendige historien og fremtidige regler for hver region, inkludert sommertidsoverganger, politiske endringer og historiske anomalier. Denne informasjonen finnes i IANA Time Zone Database (også kalt Olson-databasen eller tzdata).

Den bruker identifikatorer som America/New_York, Europe/Paris, Asia/Tokyo. Hver oppføring koder den fullstendige historien av UTC-forskyvninger og sommertidsregler for det stedet.

Det er derfor du aldri bør lagre en tidssone som en fast forskyvning som «+02:00». En forskyvning forteller deg den nåværende forskjellen fra UTC, men sier ingenting om sommertidsregler. Europe/Paris er UTC+1 om vinteren og UTC+2 om sommeren. IANA-identifikatoren fanger begge deler.

Vanlige feil i programvare

1. Lagrer lokal tid uten tidssone. En verdi som 2026-03-29 14:30:00 er meningsløs uten å vite hvilken tidssone den refererer til. Lagre alltid UTC eller inkluder forskyvningen.
2. Antar at UTC-forskyvning er det samme som tidssone. UTC+2 i mars kan være UTC+3 i juli (hvis regionen observerer sommertid). Lagre IANA-identifikatoren, ikke forskyvningen.
3. Ignorerer sommertidsoverganger i planlegging. En daglig jobb kl. 02:30 vil hoppe over én gang i året og kjøre to ganger én gang i året hvis du ikke håndterer sommertid.
4. Antar at dager har 24 timer. På sommertidsovergangsdager har en dag 23 eller 25 timer. Å beregne «i morgen på samme tid» ved å legge til 86 400 sekunder vil være en time feil.
5. Bruker JavaScript Date naivt. new Date("2026-03-29") parses som UTC i noen motorer og som lokal tid i andre. Vær alltid eksplisitt om tidssonen.

Beste praksis for utviklere

• Lagre tider i UTC. Konverter til brukerens lokale tidssone kun i presentasjonslaget.
• Bruk IANA-tidssoneidentifikatorer (America/New_York), ikke faste forskyvninger (-05:00).
• Bruk ISO 8601 for serialisering. Det er entydig og universelt parserbart.
• Bruk et modent datobibliotek. I JavaScript, bruk Intl.DateTimeFormat eller et bibliotek som date-fns-tz. I Python, bruk zoneinfo (3.9+) eller pytz. I Java, bruk java.time.ZonedDateTime.
• Hold tzdata oppdatert. Regjeringer endrer sommertidsregler. Operativsystemet og runtime-miljøet ditt trenger aktuelle tidssone-data.
• Test med flere tidssoner. Ikke anta at serveren og brukerne dine deler samme sone.

Gå videre

Tid er villedende komplekst, men reglene er godt dokumentert og verktøyene er modne. Nøkkelen er å respektere kompleksiteten fremfor å anta den bort.

• Cron-uttrykk avmystifisert — planlegging av oppgaver på tvers av tidssoner
• Hash-generator og Regex-tester — flere utviklerverktøy på ToolK