IANA-tidszonedatabasen (tz): Hvad den er, og hvorfor den betyder noget

Hvad IANA-tidszonedatabasen faktisk er

Hvis du nogensinde har arbejdet med datoer og tidspunkter i software, har du brugt IANA-tidszonedatabasen, uanset om du vidste det eller ej. Den går under flere navne — tz-databasen, tzdata, Olson-databasen eller zoneinfo — men de refererer alle til det samme: et samarbejdsbaseret, frit tilgængeligt katalog over verdens tidszoner og de regler, der styrer dem.

Ordet "katalog" underdriver det. Databasen lister ikke blot, hvilke regioner der ligger på hvilket UTC-offset. Den registrerer den fuldstændige historie for civil tidsregning for hver region — hvert offset-skift, hver overgang til sommertid, hvert krigstids-urskift og hver planlagt fremtidig regel — i mange tilfælde tilbage til midten af det 19. århundrede, da lokal middeltid vige pladsen for standardiserede zoner. Når din kalenderapp korrekt viser, at et møde i 1985 fandt sted en time forskudt fra det samme klokkeslæt i dag, er det tz-databasen på arbejde.

Den er tekstbaseret, menneskelæselig og lille. Den kompilerede binære form, der følger med din computer, er kun et par megabyte. Alligevel koder den et af de mest stille komplicerede datasæt inden for computervidenskab.

En kort historie

Projektet startede i 1980'erne under Arthur David Olson, som samlede den første version og hostede den på servere ved U.S. National Institutes of Health. I årtier blev den hovedsageligt vedligeholdt gennem en frivillig indsats koordineret over en offentlig mailingliste, hvilket er grunden til, at det ældre navn "Olson-databasen" stadig optræder i dokumentation.

Paul Eggert overtog som primær redaktør og er fortsat den mangeårige koordinator af projektet. Hans kompilering af det medfølgende theory.html-dokument og den omhyggelige commit-historik har gjort databasen lige så meget til en historisk reference som en teknisk.

I 2011, efter en kort, men alarmerende juridisk tvist om de historiske data, flyttede forvaltningen til Internet Assigned Numbers Authority (IANA), samme organ, der koordinerer andre centrale internetressourcer. IANA udgiver nu officielle udgivelser, hvilket er grunden til, at "IANA-tidszonedatabase" er blevet det kanoniske navn. Arbejdet udføres stadig af det samme fællesskab af bidragydere; IANA giver et institutionelt hjem og et stabilt distributionspunkt.

Navnekonventionen: Område/Lokation

En af databasens mest karakteristiske træk er, hvordan den navngiver zoner. I stedet for landenavne eller rå offsets bruger den et Område/Lokation-format, næsten altid forankret til en repræsentativ by:

• America/New_York
• Europe/London
• Asia/Kolkata
• Australia/Sydney

"Området" er normalt et kontinent eller et hav (America, Europe, Asia, Pacific), og "Lokationen" er en velkendt by inden for zonen. Dette valg virker sært, indtil du forstår ræsonnementet bag det.

Byer er stabile; politiske grænser og offsets er det ikke. Lande deler sig, fusionerer, omdøber sig selv og ændrer deres ure. En by er derimod et fast geografisk punkt med en kontinuerlig tidsregningshistorie. At navngive en zone America/New_York i stedet for "US Eastern Time" eller "UTC-5" betyder, at identifikatoren forbliver gyldig, selv når de regler, der er knyttet til den, udvikler sig.

Databasen undgår også bevidst landenavne for at omgå politiske stridigheder, og fordi et enkelt land ofte indeholder flere zoner — USA har mere end et dusin. Den vælger den mest befolkede eller historisk betydningsfulde by i hver distinkt zone som en neutral etiket. Når to regioner har delt identisk urhistorik siden 1970, deler de én zone; i det øjeblik deres historier divergerer, får de separate indgange.

Hvorfor rå offsets ikke er nok

En almindelig begynderinstinkt er at gemme et tidspunkt som "UTC+5:30" og kalde det færdigt. Dette fungerer for et enkelt øjeblik, men det falder fra hinanden, så snart du har brug for at ræsonnere om fremtidige eller tilbagevendende begivenheder, fordi offsets ikke er statiske egenskaber ved et sted. De er outputtet af regler, som regeringer ændrer konstant og ofte brat.

Overvej et par virkelige eksempler, databasen har måttet absorbere:

• Samoa sprang 30. december 2011 helt over. For at tilpasse sin arbejdsdag til Australien og New Zealand i stedet for USA sprang Samoa over den internationale datolinje og flyttede fra UTC-11 til UTC+13. For alle på øerne eksisterede den fredag simpelthen ikke.
• Lande afskaffer, indfører eller omlægger sommertid med kort varsel. Den Europæiske Union har debatteret at afskaffe sommertid; flere lande og amerikanske stater har ændret deres sommertidsregler i de seneste årtier. Tyrkiet, Rusland og andre har helt ændret deres standardoffsets.
• Sommertids start- og slutdatoer flytter sig. USA flyttede sine sommertidsgrænser i 2007. Ethvert system, der hardkodede den gamle regel, producerede stille og roligt forkerte tidspunkter i ugevis hvert år.

Hvis du kun gemmer et offset, kan du ikke besvare spørgsmålet "hvad bliver lokaltiden i Santiago den 15. november næste år?" — fordi svaret afhænger af regler, der måske ikke engang er endelige endnu. At gemme zoneidentifikatoren (America/Santiago) plus databasen lader software beregne det korrekte offset for ethvert øjeblik, fortid eller fremtid, og genberegne det automatisk, når reglerne ændres.

Dette er kerneværditilbuddet: tz-databasen adskiller identiteten af et sted fra de evigt skiftende regler, der bestemmer dets ur.

Hvordan den vedligeholdes

Vedligeholdelse sker i åbenhed. Foreslåede ændringer — en ny sommertidsregel, en korrigeret historisk dato, en regeringsmeddelelse — diskuteres på den offentlige tz-mailingliste, hvor bidragydere citerer officielle tidender, nyhedsrapporter og regeringsdekreter som bevis. Nøjagtighed tages alvorligt; ændringer af historiske data bliver især gransket op imod primærkilder.

Udgivelser versionsnummereres med et år og et bogstav: 2024a, 2024b, 2024c og så videre. Tallet er året; bogstavet stiger med hver udgivelse det år. Fordi regeringer annoncerer urændringer på deres egne uforudsigelige tidsplaner, er der ingen fast udgivelseskadence — et stille år kan have to udgivelser, mens et år med politisk omvæltning har mange. Systemer forventes at opdatere hurtigt, da en forældet database kan betyde at vise det forkerte tidspunkt, efter en regelændring træder i kraft.

Hvem er afhængig af den

Næsten alt.

• Operativsystemer. Linux-distributioner leverer tzdata som en kerne-pakke. macOS henter sin zonedata fra samme kilde. Windows bruger sine egne registerbaserede zoner af historiske årsager, men eksponerer IANA-zoner gennem ICU-biblioteket og moderne API'er.
• Programmeringssprog. Stort set alle modne dato/tids-biblioteker læser fra eller inkluderer tz-databasen: Pythons zoneinfo, Javas java.time, ICU-projektet, PostgreSQL, JavaScript-motorer via ICU, Ruby, PHP og mange flere.
• Applikationer. Kalendere, bookingsystemer, finansielle handelsplatforme, loganalyseværktøjer og planlægningstjenester stoler alle på den, ofte uden at deres udviklere tænker over det.

Denne allestedsnærværelse er netop grunden til, at databasen betyder så meget. En enkelt, delt, omhyggeligt vedligeholdt kilde til sandhed betyder, at et møde planlagt i ét system vises korrekt i et andet, på tværs af operativsystemer og sprog, årtier ind i fortiden eller fremtiden.

Hvis du vil udforske zonerne selv, kan du gennemse den fulde liste over IANA tidszoner eller se, hvordan de kortlægges på tværs af kloden i vores katalog over alle tidszoner.

Ofte stillede spørgsmål

Er tz-databasen det samme som tzdata, zoneinfo og Olson-databasen?

Ja. Dette er alle navne for det samme projekt. "tzdata" refererer normalt til datafilerne, som de er pakket til et operativsystem, "zoneinfo" til den kompilerede binære mappe, og "Olson-databasen" er det ældre historiske navn efter grundlæggeren Arthur David Olson. I dag er det officielle navn IANA-tidszonedatabasen.

Hvor ofte opdateres databasen?

Der er ingen fast tidsplan. Udgivelser udløses af virkelige begivenheder — en regering, der ændrer sine sommertidsregler eller standardoffset, eller en korrektion af historiske data. Nogle år har en enkelt udgivelse; andre har flere. Hver navngives som 2024a, 2024b, med stigende bogstav gennem året.

Hvorfor navngiver den zoner efter byer som America/New_York?

Byer er geografisk faste og har kontinuerlige tidsregningshistorier, hvorimod lande, grænser og offsets ændrer sig over tid. At bruge en repræsentativ by giver hver zone en stabil, politisk neutral identifikator, der forbliver gyldig, selv når de underliggende sommertids- eller offsetregler ændres.

Kan jeg bare gemme et UTC-offset i stedet for et zonavn?

Kun for et enkelt fast øjeblik. For fremtidige eller tilbagevendende begivenheder bør du gemme zoneidentifikatoren, fordi offsets ændrer sig med sommertid og regeringsbeslutninger. Zonenavnet plus databasen lader software beregne det korrekte offset for enhver dato automatisk.

Hvem driver projektet nu?

Det udgives af IANA, som overtog forvaltningen i 2011, og koordineres af Paul Eggert med et fællesskab af bidragydere, der arbejder over den offentlige tz-mailingliste. Det tekniske arbejde forbliver en samarbejdsbaseret, frivilligdrevet indsats.