Was ist die IANA-Zeitzonendatenbank (und warum sie wichtig ist)

Wenn Ihr Laptop an einem Sonntagmorgen unauffällig eine Stunde zurückspringt oder eine Kalendereinladung von einer Kollegin in São Paulo genau zu dem Zeitpunkt eintrifft, den Sie erwartet haben, hat dasselbe unsichtbare Element die Arbeit erledigt: ein frei gepflegter Datensatz, den nahezu jedes Betriebssystem, jede Programmiersprache und jeder Webdienst als maßgebliche Autorität für die bürgerliche Zeit behandelt. Es ist die IANA-Zeitzonendatenbank — auch tz-Datenbank, tzdata oder historisch Olson-Datenbank genannt, nach Arthur David Olson, der in den 1980er-Jahren mit ihrer Pflege begann.

Zeitzonen fühlen sich wie Geografie an, aber sie sind Politik. Eine Regierung kann beschließen, die Sommerzeit früher zu beenden, ihre Standardzeitverschiebung zu ändern oder einen ganzen Tag auszulassen — manchmal mit nur wenigen Wochen Vorlauf. Die tz-Datenbank ist das gemeinsame Regelwerk, das diese Änderungen aufnimmt, damit „Wie spät ist es in London, wenn es in New York 15 Uhr ist?" überall eine einheitliche Antwort hat. Dieser Artikel erklärt, was die Datenbank tatsächlich enthält, wie eine Aktualisierung von einem Regierungserlass bis zu Ihrem Telefon gelangt und warum die verlockende Abkürzung, eine feste Zeitverschiebung wie „UTC+1" zu speichern, ein Fehler ist, der nur darauf wartet zuzuschlagen.

Was die Datenbank tatsächlich ist

Die tz-Datenbank ist eine Sammlung von Klartextdateien, die die Regeln für die lokale Uhrzeit auf der ganzen Welt beschreiben — sowohl jetzt als auch so weit zurück, wie es die Aufzeichnungen vernünftigerweise zulassen. Man führt sie nicht aus; Software liest sie. Jeder kann sie herunterladen, und die Daten unterliegen keinerlei Lizenzbeschränkungen, was mit ein Grund dafür ist, dass sie überall gelandet sind.

Jede Region wird durch einen Zonennamen in der Form `Area/Location` identifiziert: `America/New_York`, `Europe/London`, `Asia/Kolkata`, `Australia/Lord_Howe`. Der Ort ist in der Regel eine repräsentative Stadt, kein Land, und das ist beabsichtigt. Ein einzelnes Land kann mehrere Regelsätze umfassen, und Städtenamen sind über Jahrzehnte hinweg weitaus stabiler als Grenzen oder Ländernamen. Die Datenbank definiert einige hundert dieser Zonen.

Für jede Zone erfasst die Datenbank:

• Die Basisverschiebung gegenüber UTC — zum Beispiel liegt `America/New_York` im Winter bei UTC−5 (EST).
• Die geltenden Sommerzeitregeln, einschließlich des genauen Beginns und Endes in jedem Jahr.
• Die historischen Übergänge — jede vergangene Änderung der Zeitverschiebung oder DST-Regel dieser Zone.
• Die Abkürzungen, die in den jeweiligen Zeiträumen galten, etwa EST, EDT, CET oder IST.

Diese historische Dimension ist es, die tzdata von einer einfachen Tabelle mit Zeitverschiebungen unterscheidet. Sie weiß nicht nur, dass New York heute bei UTC−5 liegt. Sie weiß, dass die Vereinigten Staaten ab 2007 den Beginn der Sommerzeit vorverlegt haben, und sie wendet die korrekte Regel für genau das Datum an, nach dem Sie fragen. Deshalb kann ein gut gebauter Konverter Ihnen die Zeitverschiebung für ein Datum im Jahr 1995 ebenso zuverlässig nennen wie für nächsten Dienstag.

Zonen, Verweise und die verwirrenden „Etc"-Einträge

Die Datenbank definiert außerdem Verweise (links) — Aliasnamen, die einen Namen auf einen anderen verweisen, damit Umbenennungen bestehende Systeme nicht beschädigen. Als sich Indiens Zone auf `Asia/Kolkata` festlegte, wurde der ältere Name `Asia/Calcutta` als Verweis darauf beibehalten. Beide lösen weiterhin zu UTC+5:30 auf.

Es gibt außerdem `Etc/`-Zonen für feste Zeitverschiebungen, darunter `Etc/UTC` und das berühmt-berüchtigt verdrehte `Etc/GMT+5`. Dieses steht für UTC−5, nicht UTC+5: Die Namen `Etc/GMT±` kehren das Vorzeichen nach einer alten POSIX-Konvention um. Diese Zonen mit fester Verschiebung existieren für besondere technische Anforderungen. Für jeden Ort, an dem echte Menschen leben, wollen Sie eine geografische Zone — denn nur eine geografische Zone weiß über die Sommerzeit und künftige Regeländerungen Bescheid. Der nächste Abschnitt erklärt, warum das wichtig ist.

Warum sich Zeitzonenregeln so oft ändern

Die Leute nehmen an, Zeitzonen seien festgelegt. Sind sie nicht. Die tz-Datenbank wird in einem typischen Jahr mehrmals aktualisiert, manchmal öfter. Releases werden mit Jahreszahl und einem Buchstaben versioniert — `2023a`, `2023b`, `2024a` — und jedes bündelt sämtliche Regeländerungen und Korrekturen, die sich seit dem letzten angesammelt haben.

Die Änderungen stammen aus einer Handvoll wiederkehrender Quellen:

• Regierungen passen die DST-Politik an. Ein Land beginnt, die Sommerzeit zu beachten, stellt sie ein oder verschiebt die Umstellungstermine. Die Europäische Union diskutiert seit Jahren über die Abschaffung der saisonalen Zeitumstellung, und mehrere US-Bundesstaaten haben Gesetze verabschiedet, die eine dauerhafte Sommerzeit anstreben und auf die Genehmigung des Bundes warten.
• Grundlegende Änderungen der Zeitverschiebung. Gelegentlich übernimmt ein Gebiet eine völlig andere Standardzeit. Der klassische Fall: Ende 2011 ließ Samoa den 30. Dezember vollständig ausfallen und sprang auf die andere Seite der Datumsgrenze, um seine Arbeitswoche an Australien und Neuseeland anzugleichen statt an die US-Westküste.
• Kurzfristige Ankündigungen. Das ist der schwierige Teil. Eine Regierung kündigt eine Änderung manchmal Wochen — oder Tage — vor ihrem Inkrafttreten an. Betreuer und nachgelagerte Anbieter wetteifern dann darum, eine Aktualisierung auszuliefern und zu verteilen, bevor das Datum eintritt.
• Historische Korrekturen. Forscher stoßen auf alte Gesetze, Zeitungsarchive oder Eisenbahnfahrpläne, die präzisieren, wie die Zeitverschiebung einer Zone vor Jahrzehnten *war*, und auch diese Korrekturen werden eingearbeitet.

Die unverblümte Erkenntnis: Die Regel eines Ortes ist nur bis zur nächsten Regierungsentscheidung bekannt. Jedes System, das davon ausgeht, die heutigen Regeln seien dauerhaft, wird irgendwann falsch liegen.

Wie eine Aktualisierung auf Ihr Telefon gelangt

Die Datenbank wird von einer Gemeinschaft von Freiwilligen gepflegt, die sich über eine öffentliche Mailingliste abstimmen, wobei die IANA (Internet Assigned Numbers Authority) als offizielle Heimat und Verteilungsstelle dient. Eine Änderung durchläuft typischerweise folgenden Weg:

1. Jemand meldet sie auf der tz-Mailingliste, meist unter Berufung auf ein Amtsblatt der Regierung, eine offizielle Ankündigung oder Recherchen aus Primärquellen. 2. Die Betreuer überprüfen und diskutieren sie und übernehmen die Änderung dann in die betreffende Datendatei. 3. Die IANA veröffentlicht ein neues Release mit einem Versionskennzeichen wie `2024a`. 4. Nachgelagerte Verbraucher übernehmen es — Linux-Distributionen, macOS, Sprach-Laufzeitumgebungen und große Plattformen. (Windows behält sein eigenes Zeitzonenformat und ordnet es den IANA-Namen zu.) 5. Ihr Gerät übernimmt es durch ein Betriebssystem-Update, ein App-Update oder, auf Servern, durch ein Paket wie `tzdata`.

Diese Verarbeitungskette ist auch der Ort, an dem reale Fehler entstehen. Die Datenbank kann tagesaktuell sein, während ein bestimmtes Gerät es nicht ist. Ein Laptop, der die Aktualisierung verpasst hat, wendet weiterhin die alte Regel an, und die Uhr geht am Umstellungstag falsch. Die Lücke zwischen „die Regel hat sich geändert" und „jedes Gerät weiß es" ist die mit Abstand größte Quelle von Zeitzonenfehlern, die Ihnen tatsächlich begegnen werden.

Warum fest codierte Zeitverschiebungen veralten

Hier ist der Fehler, zu dessen Verhinderung das gesamte System existiert. Ein Entwickler beschließt, die Zeitzone eines Nutzers als schlichte Zahl zu speichern — `+1` — weil das effizient aussieht. Das ist gleich in dreifacher Hinsicht fehlerhaft.

• Es ignoriert die Sommerzeit. `Europe/Paris` liegt im Winter bei UTC+1 und im Sommer bei UTC+2. Ein gespeichertes `+1` stimmt nur für einen Teil des Jahres, und in jedem Frühjahr und Herbst weicht die Rechnung um eine Stunde ab.
• Es kann den Übergang selbst nicht abbilden. An dem Morgen, an dem eine Uhr vorgestellt wird, existiert eine lokale Stunde nicht; an dem Morgen, an dem sie zurückgestellt wird, kommt eine lokale Stunde zweimal vor. Eine bloße Zeitverschiebung kann nicht ausdrücken „02:30 trat zweimal auf". Eine benannte Zone, angewendet über korrekte Datumslogik, schon.
• Es friert eine Regel ein, die sich ändern wird. Schafft eine Region nächstes Jahr die Sommerzeit ab, liefert die tz-Datenbank eine Aktualisierung und jedes konforme System passt sich automatisch an. Ein fest codiertes `+1` wendet die Politik des Vorjahres für immer weiter an und erzeugt klammheimlich falsche Zeiten.

Ein durchgerechnetes Beispiel mit verifizierten Zeitverschiebungen

Planen Sie einen wiederkehrenden Anruf für jeden Montag um 09:00 Uhr in Berlin, an dem jemand in Chicago teilnimmt. Beobachten Sie, wie sich der Abstand im Lauf des Jahres verschiebt:

• Mitte Januar: Berlin gilt CET (UTC+1), Chicago gilt CST (UTC−6). Der Abstand beträgt 7 Stunden, der Anruf findet also um 02:00 Uhr in Chicago statt.
• Mitte Juli: beide sind auf Sommerzeit umgestellt — Berlin CEST (UTC+2), Chicago CDT (UTC−5). Weiterhin 7 Stunden, also weiterhin 02:00 Uhr in Chicago.
• Mitte März: die beiden Länder stellen *nicht* am selben Tag um. 2025 stellten die USA am 9. März vor, die EU aber erst am 30. März. Für diese drei Wochen war Chicago bereits auf CDT (UTC−5), während Berlin noch CET (UTC+1) galt — ein Abstand von nur 6 Stunden, wodurch der Anruf um 03:00 Uhr in Chicago stattfindet.

Ein Tool, das „Berlin = +1, Chicago = −6" speicherte, läge im Juli *und* in den überlappenden März-Wochen um eine Stunde daneben. Nur ein System, das die benannten Zonen gegen das *konkrete Datum* auflöst, liegt in jeder Woche richtig. Genau so funktionieren der Besprechungsplaner und der Konverter von Timezio: Sie fragen, welchen Ort Sie meinen, und wenden dann die aktuellen Regeln für das betreffende Datum an statt einer eingefrorenen Zahl.

Eine praktische Checkliste

Sie müssen nie eine tzdata-Datei öffnen, um von ihrer Funktionsweise zu profitieren. Fünf Gewohnheiten bringen den Nutzen in den Alltag:

• Speichern und teilen Sie Orte, keine Zeitverschiebungen. „Ich bin in `America/Los_Angeles`" übersteht Sommerzeit und politische Änderungen. „Ich bin bei UTC−8" nicht.
• Halten Sie Ihre Systeme aktuell. Der häufigste Grund dafür, dass eine Uhr an einem Umstellungswochenende falsch geht, ist ein Gerät, das das neueste `tzdata`-Release verpasst hat. Über Betriebssystem- und App-Updates erreicht Sie die Korrektur.
• Misstrauen Sie jedem Tool, das für eine Stadt eine einzelne feste Zeitverschiebung anzeigt. Wenn es das Datum nicht berücksichtigen kann, kann es die Sommerzeit nicht berücksichtigen.
• Prüfen Sie länderübergreifende Termine rund um Umstellungswochenenden und nach jeder Regierungsankündigung erneut. Genau dann beißt die Lücke zwischen Regel und Aktualisierung am stärksten zu.
• Behandeln Sie jede Antwort als vorläufig. Die heute korrekte Umrechnung ist nur bis zum nächsten Erlass korrekt.

Die IANA-Zeitzonendatenbank ist eines der leisesten Stücke gemeinsam genutzter Infrastruktur im Internet — eine von Freiwilligen gepflegte Sammlung von Textdateien, auf die sich die digitale Welt für die bürgerliche Zeit verlässt. Sie funktioniert, weil sie Zeitzonen als das behandelt, was sie wirklich sind: ein bewegliches Ziel, das von Politik geformt wird, und kein festes Raster, das auf eine Landkarte gezeichnet ist. Jede zuverlässige Umrechnung, auf die Sie sich verlassen — die von Timezio eingeschlossen —, hängt davon ab, dass irgendjemand, irgendwo, die neueste Regel aufgeschrieben und ausgeliefert hat, bevor die Uhren umgestellt wurden.