Forstå tidszoner, UTC og Unix-tidsstempler

Tid virker simpelt, indtil du forsøger at skrive software, der håndterer det korrekt. Et møde planlagt til "kl. 15" betyder noget forskelligt i Tokyo, London og New York. Sommertid rykker uret frem eller tilbage — men ikke overalt, og ikke på de samme datoer. Et tidsstempel, der ser korrekt ud i dit lokale miljø, fejler i produktion, fordi serveren er i en anden zone.

Tidszoner er et af de mest pålidelig forvirrende emner inden for softwareudvikling. Denne artikel forklarer, hvordan de fungerer, hvor kompleksiteten kommer fra, og hvordan du undgår de mest almindelige fejl.

Hvorfor tidszoner eksisterer

Jorden roterer 360 grader på 24 timer, hvilket betyder, at solen er på sit højeste punkt på forskellige tidspunkter afhængigt af din længdegrad. Før det 19. århundrede satte hver by sit ur efter lokal soltid — middag var, når solen stod højest. Det fungerede fint, indtil jernbaner forbandt fjerne byer, og en togkøreplan krævede et enkelt, konsistent ur.

I 1884 mødtes delegerede fra 25 nationer ved Den Internationale Meridiankonference i Washington, D.C. og blev enige om at opdele verden i 24 standardtidszoner, hver forskudt fra nulmeridianen (0 graders længdegrad) gennem Greenwich, England.

I praksis følger tidszoners grænser politiske grænser, ikke pæne længdegradslinjer. Kina dækker fem geografiske zoner, men bruger en enkelt officiel tid (UTC+8). Indien bruger UTC+5:30 — en halvtimeforskydning. Nepal bruger UTC+5:45. Det virkelige kort over tidszoner er rodet.

UTC vs. GMT

GMT (Greenwich Mean Time) er den gennemsnitlige soltid ved Royal Observatory i Greenwich. Det var verdens tidsreference i over et århundrede.

UTC (Coordinated Universal Time) erstattede GMT som den internationale standard i 1972. UTC er baseret på atomure frem for astronomiske observationer, hvilket gør det langt mere præcist. Til de fleste praktiske formål viser UTC og GMT den samme tid, men UTC er den korrekte tekniske reference.

Sommertid: organiseret kaos

Omkring 70 lande overholder sommertid (DST) og rykker uret en time frem om foråret og en time tilbage om efteråret. Formålet er at tilpasse vågne timer med dagslyset. Resultatet er en halvårlig kilde til fejl.

Vigtige komplikationer:

• Ikke universel. Det meste af Afrika, Asien og Sydamerika overholder ikke sommertid. Inden for USA fravælger Arizona og Hawaii det.
• Forskellige datoer. EU skifter den sidste søndag i marts og oktober. USA skifter den anden søndag i marts og den første søndag i november. De er ude af synk i flere uger hvert år.
• Tvetydige tidspunkter. Når uret stilles tilbage, forekommer timen fra kl. 01:00 til 02:00 to gange. Et tidsstempel på "01:30" den dag er tvetydigt.
• Overspringede tidspunkter. Når uret stilles frem, eksisterer timen fra kl. 02:00 til 03:00 ikke. Et møde planlagt kl. 02:30 den dag finder aldrig sted.
• Politiske ændringer. Regeringer kan (og gør det) ændre sommertidsregler med kort varsel. Rusland indførte permanent sommertid i 2011, skiftede derefter til permanent normaltid i 2014. Marokko har ændret sommertidsregler flere gange.

ISO 8601: det universelle datoformat

For at undgå tvetydighed definerer den internationale standard 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 adskiller dato fra tid.
• Z betyder UTC ("Zulu"-tidszonen i militær terminologi).
• +02:00 eller -05:00 er UTC-forskydningen.

Dette format er entydigt, sorterbart som ren tekst og forstået universelt af datoparsing-biblioteker. Når du er i tvivl, brug ISO 8601.

Unix-tidsstempler

Et Unix-tidsstempel (også kaldet epoch-tid eller POSIX-tid) er antallet af sekunder, der er gået siden 1. januar 1970, 00:00:00 UTC — et øjeblik kendt som Unix-epoken.

Unix-tidsstempler har ingen tidszone — de er altid i UTC. Det gør dem ideelle til at gemme og sammenligne tider i software. Du konverterer kun til en lokal tidszone i visningslaget.

IANA-tidszonedatabasen

Software har ikke kun brug for UTC-forskydninger — den har brug for at kende den fulde historie og fremtidige regler for hver region, inklusive sommertidsovergange, politiske ændringer og historiske anomalier. Denne information findes i IANA Time Zone Database (også kaldet Olson-databasen eller tzdata).

Den bruger identifikatorer som America/New_York, Europe/Paris, Asia/Tokyo. Hver post koder den fulde historie af UTC-forskydninger og sommertidsregler for den pågældende lokation.

Det er derfor, du aldrig bør gemme en tidszone som en fast forskydning som "+02:00". En forskydning fortæller dig den aktuelle forskel fra UTC, men siger intet om sommertidsregler. Europe/Paris er UTC+1 om vinteren og UTC+2 om sommeren. IANA-identifikatoren fanger begge dele.

Almindelige fejl i software

1. Gemmer lokal tid uden tidszone. En værdi som 2026-03-29 14:30:00 er meningsløs uden at vide, hvilken tidszone den refererer til. Gem altid UTC eller inkludér forskydningen.
2. Antager at UTC-forskydning er lig med tidszone. UTC+2 i marts kan være UTC+3 i juli (hvis regionen overholder sommertid). Gem IANA-identifikatoren, ikke forskydningen.
3. Ignorerer sommertidsovergange i planlægning. Et dagligt job kl. 02:30 vil springe over én gang om året og køre to gange én gang om året, hvis du ikke håndterer sommertid.
4. Antager at dage har 24 timer. På sommertidsovergangsdage har en dag 23 eller 25 timer. At beregne "i morgen på samme tid" ved at tilføje 86.400 sekunder vil være en time forkert.
5. Bruger JavaScript Date naivt. new Date("2026-03-29") parses som UTC i nogle motorer og som lokal tid i andre. Vær altid eksplicit om tidszonen.

Bedste praksis for udviklere

• Gem tider i UTC. Konvertér kun til brugerens lokale tidszone i præsentationslaget.
• Brug IANA-tidszoneidentifikatorer (America/New_York), ikke faste forskydninger (-05:00).
• Brug ISO 8601 til serialisering. Det er entydigt og universelt parserbart.
• Brug et modent datobibliotek. I JavaScript, brug Intl.DateTimeFormat eller et bibliotek som date-fns-tz. I Python, brug zoneinfo (3.9+) eller pytz. I Java, brug java.time.ZonedDateTime.
• Hold tzdata opdateret. Regeringer ændrer sommertidsregler. Dit operativsystem og din runtime har brug for aktuelle tidszone-data.
• Test med flere tidszoner. Antag ikke, at din server og dine brugere deler den samme zone.

Gå videre

Tid er vildledende komplekst, men reglerne er veldokumenterede, og værktøjerne er modne. Nøglen er at respektere kompleksiteten frem for at antage den væk.

• Cron-udtryk afmystificeret — planlægning af opgaver på tværs af tidszoner
• Hash-generator og Regex-tester — flere udviklerværktøjer på ToolK