De IANA-tijdzonedatabase (tz): wat het is en waarom het belangrijk is

Wat de IANA-tijdzonedatabase werkelijk is

Als je ooit met datums en tijden in software hebt gewerkt, heb je vertrouwd op de IANA-tijdzonedatabase, of je het nu wist of niet. Het staat bekend onder verschillende namen — tz-database, tzdata, de Olson-database of zoneinfo — maar ze verwijzen allemaal naar hetzelfde: een gezamenlijke, vrij beschikbare catalogus van de wereldtijdzones en de regels die ze beheersen.

Het woord "catalogus" doet het tekort. De database vermeldt niet alleen welke regio's op welke UTC-offset liggen. Het registreert de volledige geschiedenis van de burgerlijke tijdwaarneming voor elke regio — elke offsetwijziging, elke zomertijdovergang, elke klokverschuiving in oorlogstijd en elke geplande toekomstige regel — die in veel gevallen teruggaat tot het midden van de 19e eeuw, toen de lokale gemiddelde tijd plaatsmaakte voor gestandaardiseerde zones. Wanneer je kalender-app correct weergeeft dat een vergadering in 1985 een uur afweek van dezelfde kloktijd vandaag, is dat de tz-database aan het werk.

Het is op tekst gebaseerd, leesbaar voor mensen en klein. De gecompileerde binaire vorm die op je computer wordt meegeleverd, is slechts een paar megabytes groot. Toch codeert het een van de meest stilletjes complexe datasets in de computerwereld.

Een korte geschiedenis

Het project begon in de jaren 80 onder Arthur David Olson, die de eerste versie samenstelde en hostte op servers van de Amerikaanse National Institutes of Health. Decennialang werd het grotendeels onderhouden door vrijwilligerswerk, gecoördineerd via een openbare mailinglijst, wat verklaart waarom de oudere naam "Olson-database" nog steeds in documentatie voorkomt.

Paul Eggert nam de rol van hoofdredacteur over en blijft de langdurige coördinator van het project. Zijn compilatie van het bijbehorende theory.html-document en de nauwgezette commit-geschiedenis hebben de database net zozeer een historische referentie gemaakt als een technische.

In 2011, na een kort maar alarmerend juridisch geschil over de historische gegevens, verhuisde het beheer naar de Internet Assigned Numbers Authority (IANA), dezelfde instantie die andere kerninternetbronnen coördineert. IANA publiceert nu officiële releases, wat verklaart waarom "IANA-tijdzonedatabase" de canonieke naam is geworden. Het werk wordt nog steeds gedaan door dezelfde gemeenschap van bijdragers; IANA biedt een institutionele thuisbasis en een stabiel distributiepunt.

De naamgevingsconventie: Gebied/Locatie

Een van de meest kenmerkende eigenschappen van de database is hoe het zones benoemt. In plaats van landnamen of ruwe offsets gebruikt het een Gebied/Locatie-formaat, bijna altijd verankerd aan een representatieve stad:

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

Het "Gebied" is meestal een continent of oceaan (America, Europe, Asia, Pacific), en de "Locatie" is een bekende stad binnen de zone. Deze keuze ziet er eigenaardig uit totdat je de redenatie erachter begrijpt.

Steden zijn stabiel; politieke grenzen en offsets zijn dat niet. Landen splitsen, fuseren, hernoemen zichzelf en veranderen hun klokken. Een stad daarentegen is een vast geografisch punt met een continue tijdwaarnemingsgeschiedenis. Het benoemen van een zone als America/New_York in plaats van "US Eastern Time" of "UTC-5" betekent dat de identificatiecode geldig blijft, zelfs als de regels die eraan zijn gekoppeld, evolueren.

De database vermijdt ook bewust landnamen om politieke geschillen te omzeilen en omdat een enkel land vaak meerdere zones bevat — de Verenigde Staten hebben er meer dan een dozijn. Het kiest de meest bevolkte of historisch significante stad in elke afzonderlijke zone als een neutraal label. Wanneer twee regio's sinds 1970 een identieke klokgeschiedenis hebben gedeeld, delen ze één zone; zodra hun geschiedenissen uiteenlopen, krijgen ze aparte vermeldingen.

Waarom ruwe offsets niet volstaan

Een veelvoorkomend instinct van beginners is om een tijd op te slaan als "UTC+5:30" en het daarbij te laten. Dit werkt voor een enkel moment, maar het valt uit elkaar zodra je moet redeneren over toekomstige of terugkerende gebeurtenissen, omdat offsets geen statische eigenschappen van een plaats zijn. Ze zijn de uitvoer van regels die overheden voortdurend en vaak abrupt veranderen.

Overweeg een paar echte voorbeelden die de database heeft moeten verwerken:

• Samoa sloeg 30 december 2011 volledig over. Om zijn werkdag af te stemmen op Australië en Nieuw-Zeeland in plaats van de Verenigde Staten, sprong Samoa over de internationale datumgrens, van UTC-11 naar UTC+13. Voor iedereen op de eilanden bestond die vrijdag simpelweg niet.
• Landen schaffen zomertijd af, voeren het in of passen het schema aan met weinig waarschuwing. De Europese Unie heeft gedebatteerd over het afschaffen van zomertijd; verschillende landen en Amerikaanse staten hebben hun zomertijdregels in de afgelopen decennia gewijzigd. Turkije, Rusland en anderen hebben hun standaardoffsets volledig verschoven.
• Begin- en einddata van zomertijd verschuiven. De Verenigde Staten verplaatsten hun zomertijdgrenzen in 2007. Elk systeem dat de oude regel hardcodeerde, produceerde wekenlang stilletjes verkeerde tijden per jaar.

Als je alleen een offset opslaat, kun je de vraag "hoe laat zal het lokaal zijn in Santiago op 15 november volgend jaar?" niet beantwoorden — omdat het antwoord afhangt van regels die misschien nog niet eens zijn afgerond. Het opslaan van de zone-identificatiecode (America/Santiago) plus de database stelt software in staat om de juiste offset voor elk moment, verleden of toekomst, te berekenen en deze automatisch opnieuw te berekenen wanneer de regels veranderen.

Dit is de kernwaardepropositie: de tz-database scheidt de identiteit van een plaats van de voortdurend veranderende regels die de klok bepalen.

Hoe het wordt onderhouden

Onderhoud gebeurt in de openbaarheid. Voorgestelde wijzigingen — een nieuwe zomertijdregel, een gecorrigeerde historische datum, een overheidsaankondiging — worden besproken op de openbare tz-mailinglijst, waar bijdragers officiële staatsbladen, nieuwsberichten en overheidsbesluiten als bewijs citeren. Nauwkeurigheid wordt serieus genomen; wijzigingen aan historische gegevens worden in het bijzonder getoetst aan primaire bronnen.

Releases worden geversied met een jaar en een letter: 2024a, 2024b, 2024c, enzovoort. Het getal is het jaar; de letter neemt toe met elke release dat jaar. Omdat overheden klokwijzigingen aankondigen op hun eigen onvoorspelbare schema's, is er geen vaste release-cadans — een rustig jaar kan twee releases zien, terwijl een jaar met politieke omwentelingen er veel ziet. Systemen worden geacht snel bij te werken, omdat een verouderde database kan betekenen dat de verkeerde tijd wordt weergegeven nadat een regelwijziging van kracht wordt.

Wie ervan afhankelijk is

Bijna alles.

• Besturingssystemen. Linux-distributies leveren tzdata als een kernpakket. macOS haalt zijn zonegegevens uit dezelfde bron. Windows gebruikt om legacy-redenen zijn eigen registergebaseerde zones, maar stelt IANA-zones beschikbaar via de ICU-bibliotheek en moderne API's.
• Programmeertalen. Vrijwel elke volwassen datum/tijd-bibliotheek leest uit of bundelt de tz-database: Python's zoneinfo, Java's java.time, het ICU-project, PostgreSQL, JavaScript-engines via ICU, Ruby, PHP en vele andere.
• Toepassingen. Kalenders, boekingssystemen, financiële handelsplatforms, loganalysetools en planningsdiensten steunen er allemaal op, meestal zonder dat hun ontwikkelaars erover nadenken.

Deze alomtegenwoordigheid is precies waarom de database zo belangrijk is. Een enkele, gedeelde, zorgvuldig onderhouden bron van waarheid betekent dat een vergadering die in het ene systeem is gepland, correct wordt weergegeven in een ander systeem, over besturingssystemen en talen heen, decennia in het verleden of de toekomst.

Als je de zones zelf wilt verkennen, blader dan door de volledige lijst van IANA tijdzones of zie hoe ze over de hele wereld zijn afgebeeld in onze directory van alle tijdzones.

Veelgestelde vragen

Is de tz-database hetzelfde als tzdata, zoneinfo en de Olson-database?

Ja. Dit zijn allemaal namen voor hetzelfde project. "tzdata" verwijst meestal naar de gegevensbestanden zoals verpakt voor een besturingssysteem, "zoneinfo" naar de gecompileerde binaire directory, en "Olson-database" is de oudere historische naam naar oprichter Arthur David Olson. Tegenwoordig is de officiële naam de IANA-tijdzonedatabase.

Hoe vaak wordt de database bijgewerkt?

Er is geen vast schema. Releases worden getriggerd door gebeurtenissen in de echte wereld — een overheid die zijn zomertijdregels of standaardoffset wijzigt, of een correctie van historische gegevens. Sommige jaren kennen een enkele release; andere jaren meerdere. Elke wordt genoemd zoals 2024a, 2024b, waarbij de letter door het jaar heen toeneemt.

Waarom benoemt het zones naar steden zoals America/New_York?

Steden zijn geografisch vast en hebben continue tijdwaarnemingsgeschiedenissen, terwijl landen, grenzen en offsets in de loop van de tijd veranderen. Het gebruik van een representatieve stad geeft elke zone een stabiele, politiek neutrale identificatiecode die geldig blijft, zelfs wanneer de onderliggende zomertijd- of offsetregels veranderen.

Kan ik gewoon een UTC-offset opslaan in plaats van een zonenaam?

Alleen voor een enkel vast moment. Voor toekomstige of terugkerende gebeurtenissen moet je de zone-identificatiecode opslaan, omdat offsets veranderen met zomertijd en overheidsbeslissingen. De zonenaam plus de database stelt software in staat om de juiste offset voor elke datum automatisch te berekenen.

Wie runt het project nu?

Het wordt gepubliceerd door IANA, dat in 2011 het beheer overnam, en gecoördineerd door Paul Eggert met een gemeenschap van bijdragers die werken via de openbare tz-mailinglijst. Het technische werk blijft een gezamenlijke, door vrijwilligers gedreven inspanning.