IANA:s tidszonsdatabas (tz): Vad det är och varför det är viktigt

Vad IANA:s tidszonsdatabas egentligen är

Om du någonsin har arbetat med datum och tider i mjukvara har du förlitat dig på IANA:s tidszonsdatabas, oavsett om du visste om det eller inte. Den går under flera namn — tz-databasen, tzdata, Olson-databasen eller zoneinfo — men de syftar alla på samma sak: en samarbetsbaserad, fritt tillgänglig katalog över världens tidszoner och de regler som styr dem.

Ordet "katalog" underskattar det. Databasen listar inte bara vilka regioner som ligger på vilken UTC-offset. Den registrerar hela historien av civil tidsmätning för varje region — varje offsetändring, varje övergång till sommartid, varje krigstida klockförskjutning och varje planerad framtida regel — i många fall ända tillbaka till mitten av 1800-talet när lokal medeltid gav vika för standardiserade zoner. När din kalenderapp korrekt visar att ett möte 1985 inträffade en timme bort från samma klocktid idag, är det tz-databasen i arbete.

Den är textbaserad, läsbar för människor och liten. Den kompilerade binärformen som följer med din dator är bara några megabyte. Ändå kodar den en av de mest tyst komplicerade datamängderna inom databehandling.

En kort historia

Projektet började på 1980-talet under Arthur David Olson, som sammanställde den första versionen och värdade den på servrar vid U.S. National Institutes of Health. I årtionden underhölls den till stor del genom frivilliginsatser samordnade via en offentlig e-postlista, vilket är anledningen till att det äldre namnet "Olson-databasen" fortfarande förekommer i dokumentation.

Paul Eggert tog över som huvudredaktör och är fortfarande projektets långvariga samordnare. Hans sammanställning av det medföljande theory.html-dokumentet och den noggranna commit-historiken har gjort databasen lika mycket en historisk referens som en teknisk sådan.

År 2011, efter en kort men oroande juridisk tvist om de historiska uppgifterna, flyttades förvaltningen till Internet Assigned Numbers Authority (IANA), samma organ som samordnar andra centrala internetresurser. IANA publicerar nu officiella utgåvor, vilket är anledningen till att "IANA:s tidszonsdatabas" har blivit det kanoniska namnet. Arbetet utförs fortfarande av samma gemenskap av bidragsgivare; IANA tillhandahåller ett institutionellt hem och en stabil distributionspunkt.

Namnkonventionen: Area/Location

En av databasens mest utmärkande egenskaper är hur den namnger zoner. Istället för landsnamn eller råa offsetvärden använder den ett Area/Location-format, nästan alltid förankrat i en representativ stad:

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

"Area" är vanligtvis en kontinent eller ett hav (America, Europe, Asia, Pacific), och "Location" är en välkänd stad inom zonen. Detta val ser udda ut tills du förstår resonemanget bakom det.

Städer är stabila; politiska gränser och offsetvärden är det inte. Länder delas, slås samman, byter namn och ändrar sina klockor. En stad är däremot en fast geografisk punkt med en kontinuerlig tidsmätningshistoria. Att namnge en zon America/New_York istället för "US Eastern Time" eller "UTC-5" innebär att identifieraren förblir giltig även när de regler som är kopplade till den utvecklas.

Databasen undviker också medvetet landsnamn för att kringgå politiska tvister och eftersom ett enda land ofta innehåller flera zoner — USA har mer än ett dussin. Den väljer den mest befolkade eller historiskt betydelsefulla staden i varje distinkt zon som en neutral etikett. När två regioner har delat identisk klockhistoria sedan 1970 delar de en zon; i samma stund som deras historier skiljer sig åt får de separata poster.

Varför råa offsetvärden inte räcker

En vanlig nybörjarinstinkt är att lagra en tid som "UTC+5:30" och anse det klart. Detta fungerar för ett enda ögonblick, men det faller samman så fort du behöver resonera om framtida eller återkommande händelser, eftersom offsetvärden inte är statiska egenskaper hos en plats. De är resultatet av regler som regeringar ändrar ständigt och ofta abrupt.

Betrakta några verkliga exempel som databasen har fått absorbera:

• Samoa hoppade över 30 december 2011 helt och hållet. För att anpassa sin arbetsdag till Australien och Nya Zeeland snarare än USA, hoppade Samoa över den internationella datumlinjen och flyttade från UTC-11 till UTC+13. För alla på öarna existerade helt enkelt inte den fredagen.
• Länder avskaffar, inför eller ändrar sommartid med kort varsel. Europeiska unionen har debatterat att avskaffa sommartid; flera länder och amerikanska delstater har ändrat sina sommartidsregler under de senaste decennierna. Turkiet, Ryssland och andra har helt ändrat sina standardoffsetvärden.
• Sommartidens start- och slutdatum förskjuts. USA flyttade sina sommartidsgränser 2007. Alla system som hårdkodade den gamla regeln producerade tyst felaktiga tider i veckor varje år.

Om du bara lagrar en offset kan du inte svara på frågan "vad blir lokal tid i Santiago den 15 november nästa år?" — eftersom svaret beror på regler som kanske inte ens är fastställda än. Att lagra zonsidentifieraren (America/Santiago) plus databasen låter mjukvaran beräkna rätt offset för varje ögonblick, förflutet eller framtida, och beräkna om den automatiskt när reglerna ändras.

Detta är kärnvärdet: tz-databasen separerar identiteten hos en plats från de ständigt föränderliga regler som bestämmer dess klocka.

Hur den underhålls

Underhållet sker öppet. Föreslagna ändringar — en ny sommartidsregel, ett korrigerat historiskt datum, ett regeringsmeddelande — diskuteras på den offentliga tz-e-postlistan, där bidragsgivare citerar officiella tidningar, nyhetsrapporter och regeringsdekret som bevis. Noggrannhet tas på allvar; ändringar av historiska data granskas särskilt mot primärkällor.

Utgåvor versionsmärks med ett år och en bokstav: 2024a, 2024b, 2024c och så vidare. Siffran är året; bokstaven ökar med varje utgåva det året. Eftersom regeringar tillkännager klockändringar enligt sina egna oförutsägbara scheman finns det ingen fast utgivningstakt — ett lugnt år kan ha två utgåvor, medan ett år med politisk turbulens har många. System förväntas uppdatera snabbt, eftersom en föråldrad databas kan innebära att fel tid visas efter att en regeländring trätt i kraft.

Vem är beroende av den

Nästan allt.

• Operativsystem. Linuxdistributioner levererar tzdata som ett kärnpaket. macOS hämtar sina zondata från samma källa. Windows använder sina egna registerbaserade zoner av historiska skäl men exponerar IANA-zoner via ICU-biblioteket och moderna API:er.
• Programspråk. I stort sett alla mogna datum-/tidsbibliotek läser från eller innehåller tz-databasen: Pythons zoneinfo, Javas java.time, ICU-projektet, PostgreSQL, JavaScript-motorer via ICU, Ruby, PHP och många fler.
• Applikationer. Kalendrar, bokningssystem, finansiella handelsplattformar, logganalysverktyg och schemaläggningstjänster förlitar sig alla på den, vanligtvis utan att deras utvecklare tänker på det.

Denna allestädesnärvaro är precis varför databasen är så viktig. En enda, delad, noggrant underhållen sanningskälla innebär att ett möte som schemalagts i ett system visas korrekt i ett annat, över operativsystem och språk, årtionden in i det förflutna eller framtiden.

Om du vill utforska zonerna själv, bläddra i hela listan över IANA tidszoner eller se hur de kartläggs över hela världen i vår katalog över alla tidszoner.

Vanliga frågor

Är tz-databasen samma sak som tzdata, zoneinfo och Olson-databasen?

Ja. Detta är alla namn för samma projekt. "tzdata" syftar vanligtvis på datafilerna som paketerats för ett operativsystem, "zoneinfo" på den kompilerade binärkatalogen och "Olson-databasen" är det äldre historiska namnet efter grundaren Arthur David Olson. Idag är det officiella namnet IANA:s tidszonsdatabas.

Hur ofta uppdateras databasen?

Det finns inget fast schema. Utgåvor utlöses av verkliga händelser — en regering som ändrar sina sommartidsregler eller standardoffset, eller en korrigering av historiska data. Vissa år har en enda utgåva; andra har flera. Varje namnges som 2024a, 2024b, med ökande bokstav under året.

Varför namnger den zoner efter städer som America/New_York?

Städer är geografiskt fasta och har kontinuerliga tidsmätningshistorier, medan länder, gränser och offsetvärden förändras över tid. Att använda en representativ stad ger varje zon en stabil, politiskt neutral identifierare som förblir giltig även när de underliggande sommartids- eller offsetreglerna ändras.

Kan jag bara lagra en UTC-offset istället för ett zonsnamn?

Endast för ett enda fast ögonblick. För framtida eller återkommande händelser bör du lagra zonsidentifieraren, eftersom offsetvärden ändras med sommartid och regeringsbeslut. Zonsnamnet plus databasen låter mjukvaran beräkna rätt offset för varje datum automatiskt.

Vem driver projektet nu?

Det publiceras av IANA, som tog över förvaltningen 2011, och samordnas av Paul Eggert med en gemenskap av bidragsgivare som arbetar via den offentliga tz-e-postlistan. Det tekniska arbetet förblir en samarbetsbaserad, frivilligdriven insats.