De database die je gebruikt zonder hem ooit te openen
De meeste mensen hebben nog nooit van de IANA-tijdzonedatabase gehoord, en toch vertrouwen ze er elke dag op. Wanneer je telefoon weet dat New York en Phoenix hun klok niet op dezelfde manier verzetten, wanneer een agenda-uitnodiging op het juiste lokale uur in Berlijn aankomt, of wanneer een server een UTC-timestamp omzet naar burgerlijke tijd voor São Paulo, zit daar meestal ergens een kopie van deze database onder.
Daardoor is het makkelijk om haar te onderschatten. Ze klinkt als een simpele tabel met offsets. Dat is ze niet. Het is een levend register van wetgeving, administratieve praktijk, historische reconstructie, naamgevingscompromissen en softwarebeperkingen. In de officiële IANA-beschrijving staat dat de database code en data bevat die de geschiedenis van lokale tijd voor representatieve plaatsen over de hele wereld weergeven, en dat ze wordt bijgewerkt wanneer politieke instanties tijdzonegrenzen, UTC-offsets of zomertijdregels veranderen.
Ze slaat regels op, niet alleen getallen
De eerste misvatting is dat een tijdzone alleen een getal is zoals UTC+01:00 of UTC-05:00. Een offset vertelt je het verschil met UTC op één moment. Een database-entry probeert het veranderende burgerlijke tijdgedrag van een plaats in de tijd te beschrijven: wanneer zomertijd begint, wanneer die eindigt, of de regio ooit de wettelijke standaardtijd heeft gewijzigd en welke afkortingen er werden gebruikt.
Daarom zijn America/New_York en America/Phoenix veel nuttiger dan “UTC-5” en “UTC-7”. De plaatsnaam verwijst naar een regelsysteem, niet alleen naar een huidige offset. De officiële documentatie legt ook uit dat elke hoofdentry klokken vertegenwoordigt die sinds 1970 overeenkomen. Dat is veel strenger dan vandaag dezelfde offset delen.
Waarom de namen eruitzien als Area/Locatie
De namen van de database zijn beroemd omdat ze technisch en wat vreemd ogen: Europe/Paris, Asia/Tokyo, America/Indiana/Petersburg. Ze zijn niet gekozen om mooi te zijn, maar om stabiel te blijven.
Het theorie-document van IANA beschrijft de doelen helder. Namen moeten regio’s uniek identificeren waarvan de klokken sinds 1970 overeenkomen, ongeveer aangeven waar ze liggen, bestand zijn tegen politieke verandering en portabel blijven op veel systemen. Daarom gebruiken ze meestal een continent of oceaan plus een representatieve plaats, niet een landnaam. Landen kunnen van naam veranderen, splitsen, fuseren of hun bestuurlijke grenzen verleggen. Steden zijn ook niet perfect, maar vaak wel de minst slechte langetermijnkeuze.
Daarom houdt de database ook oude spellingen in leven via aliassen. Het klassieke voorbeeld is Asia/Calcutta, dat werd hernoemd naar Asia/Kolkata, terwijl de oude naam voor achterwaartse compatibiliteit bleef werken. Het doel is niet taalkundige perfectie, maar continuïteit.
Waarom 1970 zo belangrijk is
Wie lang genoeg met tijdzonesoftware werkt, stuit uiteindelijk op de belangrijkste praktische grens van de database: 1970. Het officiële theorie-document zegt dat de wereld wordt opgedeeld in tijdzones waarvan de klokken overeenkomen voor timestamps na 1970-01-01 00:00:00 UTC. Die datum ligt dicht bij de POSIX-epoch en markeert het moment waarop moderne software systematisch machineleesbare burgerlijke tijd nodig krijgt.
Dat betekent niet dat eerdere geschiedenis wordt genegeerd. Veel overgangen van vóór 1970 zijn opgenomen, omdat systemen vaak oudere timestamps moeten interpreteren. Maar de beheerders zijn duidelijk over de beperking: de database is niet ontworpen om elke lokale praktijk uit de hele geschiedenis te reconstrueren. Voor nationale standaardisatie was tijd rommelig. Steden, spoorwegen, observatoria, kerken en overheden konden van elkaar verschillen. Op veel plekken is de benodigde documentatie onvolledig, tegenstrijdig of verdwenen.
Hoe wijzigingen echt in de database terechtkomen
Een ander nuttig punt is dat de database niet wordt bijgewerkt door een mysterieuze wereldtijdinstantie. Het onderhoudsproces is openbaar. RFC 6557, de IETF-richtlijn voor het beheer van de database, beschrijft een mailinglijst op [email protected] waar wijzigingen worden besproken en releases worden aangekondigd. Updates worden uitgevoerd door de aangewezen TZ-coördinator in overleg met die lijst.
Dat is belangrijk omdat tijdzoneveranderingen politiek zijn, niet astronomisch. Een parlement neemt een wet aan. Een ministerie publiceert een besluit. Een gebied schaft zomertijd af of verschuift een tijdzonegrens met weinig waarschuwing. Daarna moet iemand die wijziging opmerken, de tekst controleren, de ingangsdatum goed interpreteren, de regel omzetten naar machineleesbare data en op tijd een update uitbrengen.
De officiële IANA-documentatie benadrukt ook een ongemakkelijk punt: er bestaat geen vast releaseschema. Nieuwe versies verschijnen meestal om de paar maanden, maar regeringen plannen hun besluiten niet voor het gemak van besturingssystemen. Als een land laat een wijziging aankondigt, hebben leveranciers stroomafwaarts nog steeds tijd nodig om die te integreren, te testen en te verspreiden. Daarom zitten oude telefoons, verwaarloosde servers en embedded apparaten zo vaak fout na last-minute-wetswijzigingen.
Van tekstbestanden naar de binaire bestanden die je systeem leest
De bronvorm van de database bestaat uit mensleesbare tekst met commentaar. Maar je besturingssysteem leest geen lange discussies elke keer dat het een datum moet opmaken. De bron wordt gecompileerd naar machineleesbare binaire bestanden, één per locatie, in het TZif-formaat. Dat formaat is gestandaardiseerd door de IETF in RFC 9636, dat RFC 8536 heeft vervangen.
TZif is het bestandsformaat dat door veel Unix-achtige systemen en een grote reeks runtimebibliotheken wordt gelezen. Op de officiële IANA-pagina’s staat een indrukwekkende lijst van afnemers: GNU/Linux, Android, de BSD’s, Apple-platformen, databases, Java-runtimes, JavaScript-omgevingen via Intl, Python zoneinfo, Go, PHP, Ruby en vele andere. Zelfs wanneer twee platformen tijdzones anders tonen in hun interface, leunen ze vaak op dezelfde gedeelde bron.
Een recente mijlpaal is dat POSIX.1-2024 nu ondersteuning voor het tz-databasemodel vereist. Dat laat zien hoezeer dit ooit specialistische project gewone computerinfrastructuur is geworden.
Waarom verouderde tijdzonedata echte software breekt
Mensen stellen zich tijdzonebugs vaak voor als exotische randgevallen. In de praktijk zijn het operationele bugs. Een terugkerende vergadering wordt maanden vooruit gepland met oude regels. Een salarissysteem berekent een deadline nadat een regering haar zomertijdbeleid heeft gewijzigd. Een ticketplatform formatteert een eventtijd met oude data op de ene server en nieuwe data op de andere. Het probleem is niet dat de software geen “tijd kan vertellen”. Het probleem is dat zijn kopie van het burgerlijke tijdsrecht verouderd was.
Het theorie-document van IANA geeft een eenvoudig voorbeeld: als iemand vandaag een vergadering voor komende oktober in Casablanca plant en de regels later veranderen, kan software die blind op de oude omzetting vertrouwt fout zitten. Dat is een subtiel maar belangrijk punt. Een toekomstige lokale tijd is deels een voorspelling.
Wat de database niet belooft
Goede infrastructuur is ook nuttig omdat ze eerlijk is over haar grenzen. Het IANA-theoriebestand zegt dat de database niet autoritatief is en zeker fouten bevat. Toekomstige voorspellingen kunnen na wetswijzigingen onjuist worden. De geschiedenis van vóór 1970 is onvolledig. De database slaat geen exacte tijdzonegrenzen op. Ze garandeert ook niet dat alle klokken in een regio in het dagelijks leven altijd echt gelijk liepen. En afkortingen zoals CST of IST zijn zo dubbelzinnig dat de beheerders zelf aanraden om numerieke UTC-offsets te gebruiken wanneer duidelijkheid belangrijk is.
Waarom dit onzichtbare project ertoe doet
De IANA-tijdzonedatabase is een van de stille succesverhalen van moderne software. Ze neemt een politiek rommelig, historisch onregelmatig en wereldwijd verspreid probleem en geeft software een gedeelde woordenschat om ermee om te gaan. Geen perfecte woordenschat, en geen definitieve, maar wel een opmerkelijk effectieve.
Daarom duiken de identifiers overal op, van cloudservers tot telefooninstellingen en programmeerbibliotheken. Wanneer je apparaat na een wetswijziging toch de juiste lokale tijd blijft tonen, is dat geen magie. Het is het resultaat van een openbaar onderhoudsproces, behoudende naamgevingsregels, zorgvuldige achterwaartse compatibiliteit en een gemeenschap die burgerlijke tijd behandelt als data die voortdurend bijgehouden moet worden.