Was die IANA-Zeitzonendatenbank eigentlich ist
Wenn Sie jemals mit Daten und Zeiten in Software gearbeitet haben, haben Sie sich auf die IANA-Zeitzonendatenbank verlassen, ob Sie es wussten oder nicht. Sie ist unter mehreren Namen bekannt — tz-Datenbank, tzdata, die Olson-Datenbank oder zoneinfo — aber alle beziehen sich auf dasselbe: einen gemeinschaftlichen, frei verfügbaren Katalog der Zeitzonen der Welt und der Regeln, die sie bestimmen.
Das Wort „Katalog“ wird ihm nicht gerecht. Die Datenbank listet nicht nur auf, welche Regionen welchen UTC-Offset haben. Sie zeichnet die vollständige Geschichte der bürgerlichen Zeitmessung für jede Region auf — jede Offset-Änderung, jede Umstellung auf Sommerzeit, jede kriegsbedingte Uhrenverschiebung und jede geplante zukünftige Regel — und geht in vielen Fällen bis in die Mitte des 19. Jahrhunderts zurück, als die örtliche mittlere Zeit standardisierten Zonen wich. Wenn Ihre Kalender-App korrekt anzeigt, dass ein Meeting im Jahr 1985 um eine Stunde von derselben Wanduhrzeit heute abwich, dann ist das die tz-Datenbank in Aktion.
Sie ist textbasiert, für Menschen lesbar und klein. Die kompilierte Binärform, die auf Ihrem Computer ausgeliefert wird, ist nur wenige Megabyte groß. Dennoch kodiert sie einen der am stillsten kompliziertesten Datensätze der Informatik.
Eine kurze Geschichte
Das Projekt begann in den 1980er Jahren unter Arthur David Olson, der die erste Version zusammenstellte und sie auf Servern der US-amerikanischen National Institutes of Health hostete. Jahrzehntelang wurde es hauptsächlich durch ehrenamtliche Arbeit gepflegt, die über eine öffentliche Mailingliste koordiniert wurde, weshalb der ältere Name „Olson-Datenbank“ noch immer in der Dokumentation auftaucht.
Paul Eggert übernahm die Rolle des Hauptredakteurs und ist bis heute der langjährige Koordinator des Projekts. Seine Zusammenstellung des begleitenden Dokuments theory.html und die akribische Commit-Historie haben die Datenbank ebenso zu einer historischen Referenz wie zu einer technischen gemacht.
Im Jahr 2011, nach einem kurzen, aber alarmierenden Rechtsstreit über die historischen Daten, ging die Verantwortung an die Internet Assigned Numbers Authority (IANA) über, dieselbe Organisation, die auch andere Kernressourcen des Internets koordiniert. Die IANA veröffentlicht nun offizielle Versionen, weshalb „IANA-Zeitzonendatenbank“ zum kanonischen Namen geworden ist. Die Arbeit wird weiterhin von derselben Gemeinschaft von Mitwirkenden geleistet; die IANA bietet ein institutionelles Zuhause und eine stabile Vertriebsplattform.
Die Namenskonvention: Area/Location
Eines der markantesten Merkmale der Datenbank ist die Art und Weise, wie sie Zonen benennt. Anstatt Ländernamen oder reine Offsets zu verwenden, nutzt sie ein Area/Location-Format, das fast immer an einer repräsentativen Stadt verankert ist:
America/New_YorkEurope/LondonAsia/KolkataAustralia/Sydney
Das „Area“ ist normalerweise ein Kontinent oder Ozean (America, Europe, Asia, Pacific), und das „Location“ ist eine bekannte Stadt innerhalb der Zone. Diese Wahl wirkt skurril, bis man die dahinterstehende Logik versteht.
Städte sind stabil; politische Grenzen und Offsets sind es nicht. Länder teilen sich, fusionieren, benennen sich um und ändern ihre Uhren. Eine Stadt hingegen ist ein fester geografischer Punkt mit einer kontinuierlichen Zeitmessungsgeschichte. Eine Zone America/New_York statt „US Eastern Time“ oder „UTC-5“ zu nennen, bedeutet, dass der Bezeichner gültig bleibt, selbst wenn sich die damit verbundenen Regeln weiterentwickeln.
Die Datenbank vermeidet bewusst Ländernamen, um politische Streitigkeiten zu umgehen, und weil ein einzelnes Land oft mehrere Zonen enthält — die Vereinigten Staaten haben mehr als ein Dutzend. Sie wählt die bevölkerungsreichste oder historisch bedeutendste Stadt in jeder einzelnen Zone als neutrales Etikett. Wenn zwei Regionen seit 1970 eine identische Uhrengeschichte geteilt haben, teilen sie sich eine Zone; sobald ihre Geschichten auseinandergehen, erhalten sie separate Einträge.
Warum rohe Offsets nicht ausreichen
Ein häufiger Anfängerinstinkt ist es, eine Zeit als „UTC+5:30“ zu speichern und es dabei zu belassen. Das funktioniert für einen einzelnen Zeitpunkt, aber es bricht zusammen, sobald man über zukünftige oder wiederkehrende Ereignisse nachdenken muss, denn Offsets sind keine statischen Eigenschaften eines Ortes. Sie sind das Ergebnis von Regeln, die Regierungen ständig und oft abrupt ändern.
Betrachten Sie einige reale Beispiele, die die Datenbank aufnehmen musste:
- Samoa übersprang den 30. Dezember 2011 vollständig. Um seinen Geschäftstag an Australien und Neuseeland statt an den Vereinigten Staaten auszurichten, sprang Samoa über die internationale Datumsgrenze und wechselte von UTC-11 zu UTC+13. Für alle auf den Inseln existierte dieser Freitag einfach nicht.
- Länder schaffen die Sommerzeit ab, führen sie ein oder verschieben sie mit kurzer Vorankündigung. Die Europäische Union hat über die Abschaffung der Sommerzeit debattiert; mehrere Länder und US-Bundesstaaten haben ihre Sommerzeitregeln in den letzten Jahrzehnten geändert. Die Türkei, Russland und andere haben ihre Standard-Offsets direkt verschoben.
- Die Start- und Enddaten der Sommerzeit verschieben sich. Die Vereinigten Staaten haben ihre Sommerzeitgrenzen im Jahr 2007 verschoben. Jedes System, das die alte Regel fest codiert hatte, produzierte jedes Jahr wochenlang stillschweigend falsche Zeiten.
Wenn Sie nur einen Offset speichern, können Sie die Frage „Wie spät ist es in Santiago am 15. November nächsten Jahres?“ nicht beantworten — denn die Antwort hängt von Regeln ab, die möglicherweise noch nicht einmal endgültig festgelegt sind. Das Speichern des Zonenbezeichners (America/Santiago) zusammen mit der Datenbank ermöglicht es der Software, den korrekten Offset für jeden Zeitpunkt, vergangen oder zukünftig, zu berechnen und ihn automatisch neu zu berechnen, wenn sich die Regeln ändern.
Dies ist das zentrale Wertversprechen: Die tz-Datenbank trennt die Identität eines Ortes von den sich ständig ändernden Regeln, die seine Uhr bestimmen.
Wie sie gewartet wird
Die Wartung erfolgt öffentlich. Vorgeschlagene Änderungen — eine neue Sommerzeitregel, ein korrigiertes historisches Datum, eine Regierungsankündigung — werden auf der öffentlichen tz-Mailingliste diskutiert, wo Mitwirkende offizielle Amtsblätter, Nachrichtenberichte und Regierungsverordnungen als Belege anführen. Genauigkeit wird ernst genommen; insbesondere Änderungen an historischen Daten werden anhand von Primärquellen überprüft.
Versionen werden mit einem Jahr und einem Buchstaben nummeriert: 2024a, 2024b, 2024c und so weiter. Die Zahl ist das Jahr; der Buchstabe erhöht sich mit jeder Veröffentlichung in diesem Jahr. Da Regierungen Uhrenänderungen nach ihren eigenen unvorhersehbaren Zeitplänen ankündigen, gibt es keinen festen Veröffentlichungsrhythmus — ein ruhiges Jahr könnte zwei Versionen haben, während ein Jahr mit politischen Umwälzungen viele hat. Systeme sollten zeitnah aktualisiert werden, da eine veraltete Datenbank bedeuten kann, dass nach Inkrafttreten einer Regeländerung die falsche Uhrzeit angezeigt wird.
Wer darauf angewiesen ist
Fast alles.
- Betriebssysteme. Linux-Distributionen liefern
tzdataals Kernpaket aus. macOS bezieht seine Zonendaten aus derselben Quelle. Windows verwendet aus Legacy-Gründen eigene registrierungsbasierte Zonen, stellt aber IANA-Zonen über die ICU-Bibliothek und moderne APIs bereit. - Programmiersprachen. Praktisch jede ausgereifte Datums-/Zeitbibliothek liest aus der tz-Datenbank oder bündelt sie: Pythons
zoneinfo, Javasjava.time, das ICU-Projekt, PostgreSQL, JavaScript-Engines über ICU, Ruby, PHP und viele mehr. - Anwendungen. Kalender, Buchungssysteme, Finanzhandelsplattformen, Log-Analyse-Tools und Planungsdienste stützen sich alle darauf, normalerweise ohne dass ihre Entwickler darüber nachdenken.
Diese Allgegenwart ist genau der Grund, warum die Datenbank so wichtig ist. Eine einzige, gemeinsame, sorgfältig gepflegte Quelle der Wahrheit bedeutet, dass ein in einem System geplantes Meeting in einem anderen korrekt angezeigt wird, über Betriebssysteme und Sprachen hinweg, Jahrzehnte in die Vergangenheit oder Zukunft.
Wenn Sie die Zonen selbst erkunden möchten, durchsuchen Sie die vollständige Liste der IANA-Zeitzonen oder sehen Sie, wie sie in unserem Verzeichnis der alle Zeitzonen weltweit abgebildet sind.
Häufig gestellte Fragen
Ist die tz-Datenbank dasselbe wie tzdata, zoneinfo und die Olson-Datenbank?
Ja. Dies sind alles Namen für dasselbe Projekt. „tzdata“ bezieht sich normalerweise auf die Datendateien, wie sie für ein Betriebssystem verpackt sind, „zoneinfo“ auf das kompilierte Binärverzeichnis und „Olson-Datenbank“ ist der ältere historische Name nach dem Gründer Arthur David Olson. Heute ist der offizielle Name die IANA-Zeitzonendatenbank.
Wie oft wird die Datenbank aktualisiert?
Es gibt keinen festen Zeitplan. Veröffentlichungen werden durch reale Ereignisse ausgelöst — eine Regierung ändert ihre Sommerzeitregeln oder den Standard-Offset, oder eine Korrektur historischer Daten. Manche Jahre haben eine einzige Veröffentlichung; andere mehrere. Jede wird wie 2024a, 2024b benannt, wobei der Buchstabe im Laufe des Jahres hochgezählt wird.
Warum benennt es Zonen nach Städten wie America/New_York?
Städte sind geografisch festgelegt und haben kontinuierliche Zeitmessungsgeschichten, während Länder, Grenzen und Offsets sich im Laufe der Zeit ändern. Die Verwendung einer repräsentativen Stadt gibt jeder Zone einen stabilen, politisch neutralen Bezeichner, der auch dann gültig bleibt, wenn sich die zugrunde liegenden Sommerzeit- oder Offset-Regeln ändern.
Kann ich einfach einen UTC-Offset anstelle eines Zonennamens speichern?
Nur für einen einzelnen festen Zeitpunkt. Für zukünftige oder wiederkehrende Ereignisse sollten Sie den Zonenbezeichner speichern, da sich Offsets mit Sommerzeit und Regierungsentscheidungen ändern. Der Zonenname plus die Datenbank ermöglicht es der Software, den korrekten Offset für jedes Datum automatisch zu berechnen.
Wer leitet das Projekt jetzt?
Es wird von der IANA veröffentlicht, die 2011 die Verantwortung übernahm, und von Paul Eggert mit einer Gemeinschaft von Mitwirkenden koordiniert, die über die öffentliche tz-Mailingliste arbeiten. Die technische Arbeit bleibt eine gemeinschaftliche, ehrenamtlich getragene Anstrengung.