Zeitzonen und die IANA-Datenbank

Ein Zeitzonenbezeichner wie America/New_York oder Asia/Shanghai ist kein Anzeigename – er ist der Name eines vollständigen Regelwerks. Er erfasst für eine Region jeden Versatz zur UTC, der in Kraft war, und die genauen Daten, an denen sich die Regeln änderten: wann die Sommerzeit beginnt und endet und wann sich der zugrunde liegende Standardversatz selbst verschob. Die Stadt im Namen ist nicht dazu da, einem Nutzer angezeigt zu werden. Sie verankert diese Geschichte an einem Ort, dessen Uhren einer einheitlichen Abfolge von Gesetzen gefolgt sind.

Deshalb speichert Software, die die Zeit ernst nimmt, einen Zonenbezeichner statt eines bloßen Versatzes. „UTC-5“ sagt Ihnen, wo die Uhr in einem einzelnen Augenblick steht; America/New_York sagt Ihnen, wo sie in jedem Augenblick stehen wird, vergangen oder zukünftig, indem es die richtige Regel für dieses Datum anwendet. Die Datenbank hinter diesen Bezeichnern ist die IANA-Zeitzonendatenbank, und zu verstehen, was sie tut, erklärt eine überraschende Zahl von alltäglichen Kuriositäten.

Das Bereich/Stadt-Benennungsschema

Bezeichner folgen einem Bereich/Stadt-Muster: ein weiter Bereich – meist ein Kontinent wie America, Europe, Asia oder Africa – gefolgt von einer repräsentativen Stadt. America/New_York, Asia/Shanghai, Europe/London, Africa/Cairo. Die Stadt wird als stabiler Anker für die Regeln gewählt, nicht weil sie die größte oder die Hauptstadt ist. Asia/Shanghai etwa regelt ganz Festlandchina, obwohl das Land eine geografische Breite umfasst, die naturgemäß mehrere Zonen abdecken würde, weil China auf einer einzigen offiziellen Zeit läuft. Der Name markiert die Regelgeschichte, nicht eine Behauptung über die Geografie.

Was die tz-Datenbank tatsächlich speichert

Die tz-Datenbank – auch tzdata oder zoneinfo genannt und unter dem Dach der IANA gepflegt – ist ein jahrzehntelanges Unterfangen, die bürgerliche Zeit genau zu erfassen. Sie wurde von Arthur David Olson begründet (weshalb sie manchmal noch Olson-Datenbank genannt wird) und wird seit Langem von Paul Eggert gepflegt. Ihre Abdeckung reicht mit voller Genauigkeit bis 1970 zurück, oft auch früher, und erfasst die historischen Änderungen, die ehrliches Rechnen mit Daten möglich machen.

Weil sie Geschichte speichert statt eines einzelnen aktuellen Versatzes, kann sie Fragen beantworten, die die Uhr an Ihrer Wand nicht kann. Wie war die Ortszeit in einer bestimmten Stadt an einem bestimmten Datum vor zwanzig Jahren, bevor dieses Land die Sommerzeit abschaffte oder seinen Standardversatz verschob? Die Datenbank weiß es, weil sie die damals geltende Regel erfasste, statt die heutige Regel rückwärts zu projizieren.

Kürzel sind mehrdeutig; Versätze sind keine Zonen

Zwei Gewohnheiten verursachen die meiste Verwirrung in der Praxis, und die tz-Datenbank ist so angelegt, dass sie beiden ausweicht.

• Kürzel kollidieren. „CST“ ist nicht eine Sache. Es ist US Central Standard Time (UTC-6), China Standard Time (UTC+8) und Cuba Standard Time (UTC-5), unter anderem. Eine E-Mail, die „15 Uhr CST“ sagt, ist ohne das Wissen, welches Land der Absender meinte, wirklich mehrdeutig. Ein vollständiger Bezeichner wie America/Chicago oder Asia/Shanghai trägt keine solche Mehrdeutigkeit.
• Ein Versatz ist keine Zone. „UTC-5“ beschreibt einen Versatz in einem einzelnen Augenblick. America/New_York ist eine Zone, die zwischen UTC-5 im Winter und UTC-4 während der Sommerzeit wechselt. Den Versatz zu speichern verwirft die Regel, die entscheidet, welcher an einem zukünftigen Datum gilt; die Zone zu speichern behält sie.

Der Grund, warum Versätze und Zonen überhaupt auseinandergehen, ist die Sommerzeit, und die Mechanik dieser Umstellungstage mit 23 und 25 Stunden wird im Begleitratgeber zu Sommerzeit und dem Rechnen mit Daten behandelt.

Zonen ändern sich, und Aktualisierungen erscheinen mehrmals im Jahr

Die Datenbank ist nicht eingefroren. Länder ändern ihre Meinung: Sie schaffen die Sommerzeit ab, verschieben einen Standardversatz oder teilen und vereinen Zonen. Wenn sie das tun, erscheint eine neue Ausgabe von tzdata – das geschieht mehrmals im Jahr, nach keinem festen Kalender, getrieben davon, wann immer eine Regierung eine Änderung ankündigt. Zonen werden mit der Zeit auch umbenannt oder zusammengelegt, wenn einst getrennte Regeln konvergieren, wobei die alten Namen als Aliasse erhalten bleiben, damit bestehende Daten weiterhin aufgelöst werden. Die Datenbank aktuell zu halten ist das, was dafür sorgt, dass ein heute erstellter Kalendereintrag noch richtig ist, nachdem ein Land nächstes Jahr seine Regeln ändert.

Warum AskTheDate die Zone in die URL setzt

AskTheDate bettet in jede URL eine IANA-Zone ein – eine von 72 kuratierten Zonen–, weil dieselbe Wanduhr-Frage in verschiedenen Zonen wirklich unterschiedliche Antworten hat. Fragen Sie „welcher Tag ist heute?“ kurz vor Mitternacht, und die ehrliche Antwort hängt ganz davon ab, wo Sie stehen: In Asia/Shanghai kann bereits morgen sein, während es in America/New_York noch heute ist. Die Zone in die Adresse einzubacken macht jede Antwort eindeutig, teilbar und reproduzierbar – der Link selbst hält fest, gegen welche Uhr die Antwort berechnet wurde, sodass sie für jeden, der ihn öffnet, gleich lautet.

Sie können die Abweichung direkt sehen. Die New-York-Zeit-Seite und die Shanghai-Zeit-Seite werden sich für einen großen Teil jedes Tages über das Kalenderdatum uneins sein – kein Fehler, sondern der ganze Grund, warum es Zonen gibt.

Probieren Sie es aus

Öffnen Sie den Zeitzonenrechner für New York und rechnen Sie eine späte Abendzeit in New York nach Asia/Shanghai um. Beobachten Sie, wie das Datum auf den nächsten Tag umspringt – die klarste Demonstration auf einen Blick, warum eine Zone und nicht ein Versatz das ist, was zu speichern sich lohnt.