Die Datenbank, die Sie nutzen, ohne sie je zu öffnen
Die meisten Menschen haben noch nie von der IANA-Zeitzonendatenbank gehört, und trotzdem verlassen sie sich jeden Tag auf sie. Wenn Ihr Telefon weiß, dass New York und Phoenix ihre Uhren nicht auf dieselbe Weise umstellen, wenn eine Kalendereinladung zur richtigen Ortszeit in Berlin ankommt oder wenn ein Server einen UTC-Zeitstempel in eine Ortszeit für São Paulo umrechnet, steckt normalerweise irgendwo darunter eine Kopie dieser Datenbank.
Gerade deshalb wird sie leicht unterschätzt. Sie klingt wie eine statische Tabelle mit Offsets. In Wirklichkeit ist sie ein lebendiges Register aus Gesetzen, Verwaltungspraxis, historischen Rekonstruktionen, Namenskompromissen und Softwaregrenzen. In der offiziellen IANA-Beschreibung heißt es, dass sie Code und Daten enthält, die die Geschichte der Ortszeit für repräsentative Orte rund um den Globus abbilden, und dass sie aktualisiert wird, wenn politische Stellen Grenzen, UTC-Abweichungen oder Sommerzeitregeln ändern.
Sie speichert Regeln, nicht nur Zahlen
Der erste Irrtum ist die Annahme, eine Zeitzone sei bloß eine Zahl wie UTC+01:00 oder UTC-05:00. Ein Offset sagt nur, wie groß der Abstand zu UTC in einem bestimmten Moment ist. Ein Eintrag in der Datenbank versucht dagegen, das wechselnde zivile Zeitverhalten eines Ortes über die Zeit hinweg zu beschreiben: Beginn und Ende der Sommerzeit, mögliche Änderungen der gesetzlichen Standardzeit und verwendete Abkürzungen.
Darum sind America/New_York und America/Phoenix viel nützlicher als „UTC-5“ und „UTC-7“. Der ortsbezogene Bezeichner verweist auf ein Regelwerk, nicht nur auf einen aktuellen Offset. Die offizielle Dokumentation erklärt außerdem, dass jeder Haupteintrag Uhren repräsentiert, die seit 1970 übereingestimmt haben. Das ist deutlich anspruchsvoller, als heute denselben Offset zu teilen.
Warum die Namen wie Area/Location aussehen
Die Namen der Datenbank sind berühmt, weil sie technisch und etwas eigentümlich wirken: Europe/Paris, Asia/Tokyo, America/Indiana/Petersburg. Sie wurden nicht nach Schönheit ausgewählt, sondern nach Stabilität.
Die IANA-Theoriedatei beschreibt die Ziele klar. Namen sollen Regionen eindeutig kennzeichnen, deren Uhren seit 1970 übereinstimmen, ungefähr zeigen, wo sie liegen, politische Veränderungen überstehen und auf vielen Systemen portabel bleiben. Deshalb verwenden sie meist einen Kontinent oder Ozean und einen repräsentativen Ort statt eines Ländernamens. Staaten können ihren Namen ändern, sich teilen, fusionieren oder Verwaltungsgrenzen verschieben. Städte sind ebenfalls nicht perfekt, aber oft der am wenigsten schlechte langfristige Bezugspunkt.
Aus demselben Grund bleiben alte Schreibweisen über Aliase erhalten. Das klassische Beispiel ist Asia/Calcutta, das in Asia/Kolkata umbenannt wurde, während der alte Name aus Kompatibilitätsgründen weiter funktioniert. Es geht nicht um sprachliche Perfektion, sondern um Kontinuität.
Warum 1970 die große Trennlinie ist
Wer länger mit Zeitzonensoftware arbeitet, stößt unweigerlich auf die wichtigste praktische Grenze der Datenbank: 1970. Das offizielle Theoriedokument sagt, dass die Welt in Zeitzonen aufgeteilt wird, deren Uhren für Zeitstempel nach 1970-01-01 00:00:00 UTC übereinstimmen. Dieses Datum liegt nahe an der POSIX-Epoche und markiert den Punkt, an dem moderne Computer systematisch maschinenlesbare zivile Zeit benötigen.
Das bedeutet nicht, dass frühere Geschichte ignoriert wird. Viele Übergänge vor 1970 sind enthalten, weil Systeme oft ältere Zeitstempel interpretieren müssen. Doch die Maintainer benennen die Grenze ausdrücklich: Die Datenbank ist nicht dafür ausgelegt, jede lokale Praxis der gesamten Vergangenheit zu rekonstruieren. Vor der nationalen Standardisierung war Zeit chaotisch. Städte, Eisenbahnen, Sternwarten, Kirchen und Regierungen konnten voneinander abweichen. In vielen Regionen ist die notwendige Dokumentation unvollständig, widersprüchlich oder verloren.
Wie Änderungen tatsächlich in die Datenbank gelangen
Wichtig ist auch: Die Datenbank wird nicht von einer geheimnisvollen Weltzeitbehörde gepflegt. Der Prozess ist öffentlich. RFC 6557, die IETF-Empfehlung für die Pflege der Datenbank, beschreibt eine Mailingliste unter [email protected], auf der Änderungen diskutiert und Veröffentlichungen angekündigt werden. Updates werden vom benannten TZ-Koordinator in Abstimmung mit dieser Liste vorgenommen.
Das ist wichtig, weil Zeitzonenänderungen politisch und nicht astronomisch sind. Ein Parlament beschließt ein Gesetz. Ein Ministerium veröffentlicht eine Verordnung. Ein Gebiet schafft die Sommerzeit ab oder verschiebt seine Zeitzone kurzfristig. Dann muss jemand die Entscheidung bemerken, den Text prüfen, das Inkrafttreten korrekt deuten, die Regel in maschinenlesbare Form bringen und rechtzeitig veröffentlichen.
Die offizielle IANA-Dokumentation weist außerdem auf einen unbequemen Punkt hin: Es gibt keinen festen Veröffentlichungsplan. Neue Versionen erscheinen zwar typischerweise alle paar Monate, aber Regierungen treffen ihre Entscheidungen nicht zum Nutzen von Betriebssystemen. Wenn ein Land eine Änderung spät ankündigt, brauchen nachgelagerte Anbieter trotzdem Zeit für Integration, Tests und Verteilung. Deshalb liegen ältere Telefone, vernachlässigte Server und eingebettete Geräte nach kurzfristigen Rechtsänderungen so oft falsch.
Von Textdateien zu den Binärdateien, die Ihr System liest
Die Quelldatenbank besteht aus menschenlesbarem Text mit vielen Kommentaren. Ihr Betriebssystem liest jedoch nicht bei jeder Datumsformatierung lange Diskussionen nach. Die Quellen werden in maschinenlesbare Binärdateien übersetzt, eine pro Ort, im Format TZif. Dieses Format ist durch RFC 9636 standardisiert, der RFC 8536 ersetzt hat.
TZif wird von vielen Unix-ähnlichen Systemen und einer großen Zahl von Laufzeitbibliotheken gelesen. Die offiziellen IANA-Seiten nennen eine beeindruckende Kette von Nutzern: GNU/Linux, Android, die BSDs, Apple-Plattformen, Datenbanken, Java-Laufzeiten, JavaScript-Umgebungen über Intl, Pythons zoneinfo, Go, PHP, Ruby und viele weitere. Auch wenn zwei Plattformen Zeitzonen in ihrer Oberfläche unterschiedlich darstellen, stützen sie sich oft auf denselben gemeinsamen Datenbestand.
Ein wichtiger neuer Meilenstein ist, dass POSIX.1-2024 inzwischen Unterstützung für das tz-Datenbankmodell verlangt. Das zeigt, wie sehr dieses einst spezialisierte Projekt Teil normaler Recheninfrastruktur geworden ist.
Warum veraltete Zeitzonendaten echte Softwarefehler auslösen
Viele stellen sich Zeitzonenfehler als exotische Randfälle vor. In der Praxis sind es Betriebsfehler. Eine wiederkehrende Besprechung wird Monate im Voraus mit alten Regeln geplant. Ein Abrechnungssystem berechnet eine Frist, nachdem eine Regierung ihre Sommerzeitpolitik geändert hat. Eine Plattform formatiert eine Uhrzeit auf einem Server mit alten und auf einem anderen mit neuen Daten. Der Fehler ist nicht, dass die Software keine Zeit „anzeigen“ kann. Der Fehler ist, dass ihre Kopie des Zivilzeitrechts veraltet war.
Das IANA-Theoriedokument nennt ein einfaches Beispiel: Wenn heute jemand ein Treffen für den kommenden Oktober in Casablanca plant und die Regeln später geändert werden, kann Software, die blind der alten Umrechnung vertraut, falsch liegen. Das ist ein wichtiger Punkt. Eine zukünftige Ortszeit ist teilweise eine Vorhersage.
Was die Datenbank nicht verspricht
Gute Infrastruktur ist auch deshalb nützlich, weil sie ihre Grenzen offenlegt. Die IANA-Theoriedatei sagt ausdrücklich, dass die Datenbank nicht autoritativ ist und sicherlich Fehler enthält. Künftige Vorhersagen können durch Gesetzesänderungen falsch werden. Die Geschichte vor 1970 ist unvollständig. Exakte Zeitzonengrenzen werden nicht gespeichert. Die Datenbank garantiert nicht, dass im Alltag tatsächlich alle Uhren einer Region immer übereingestimmt haben. Und Abkürzungen wie CST oder IST sind so mehrdeutig, dass die Maintainer selbst empfehlen, bei Bedarf lieber numerische UTC-Abweichungen zu verwenden.
Warum dieses unsichtbare Projekt wichtig ist
Die IANA-Zeitzonendatenbank ist eine der stillen Erfolgsgeschichten moderner Informatik. Sie nimmt ein politisch chaotisches, historisch ungleichmäßiges und global verteiltes Problem und gibt Software ein gemeinsames Vokabular dafür. Kein perfektes, kein endgültiges, aber ein bemerkenswert wirksames.
Darum tauchen ihre Kennungen überall auf: auf Cloud-Servern, in Telefoneinstellungen und in Programmbibliotheken. Wenn Ihr Gerät nach einer Gesetzesänderung weiterhin die richtige Ortszeit anzeigt, ist das keine Magie. Es ist das Ergebnis eines öffentlichen Pflegeprozesses, vorsichtiger Namensregeln, konsequenter Rückwärtskompatibilität und einer Gemeinschaft, die zivile Zeit als Daten behandelt, die ständig gepflegt werden müssen.