IANA-Zeitzone

Eine IANA-Zeitzone ist eine kanonische Kennung wie Europe/London, America/New_Yorkoder Asia/Tokyo aus der IANA Time Zone Database (auch „tzdata“ oder „Olson-Datenbank“ nach ihrem ursprünglichen Betreuer Arthur David Olson genannt).

Jeder Eintrag erfasst jede historische und aktuelle Regel für UTC-Offset und Sommerzeitverhalten einer Region. „Europe/London“ kodiert: GMT (UTC+0) im Winter, BST (UTC+1) im Sommer, die genauen Sommerzeit-Übergangsdaten und historische Eigenheiten vor 1971. Fügt man Datum und Zone in eine moderne Programmiersprache ein, liefert sie den korrekten Offset, weil tzdata in das Betriebssystem eingebaut ist.

Die Namenskonvention ist Region/Stadt, wobei Region eine von Africa, America, Antarctica, Asia, Atlantic, Australia, Europe, Indian, Pacificist, plus die speziellen UTC, Etc/GMT usw. Stadt ist eine kanonische Stadt innerhalb der Zone – Istanbul steht für die gesamte Türkei, New_York steht für die US-Eastern-Zeitzone und so weiter.

Convertitives Zeitzonen-Konverterarbeitet über die tzdata auf OS-Ebene des Browsers via Intl.DateTimeFormat, sodass Sommerzeitübergänge und Offset-Änderungen stets aktuell sind, ohne dass Convertitive Updates ausliefern müsste.

Durchgerechnetes Beispiel

Sie planen ein wöchentlich wiederkehrendes Team-Standup „dienstags 09:00 New Yorker Zeit“ für Teilnehmer in NYC, London und Tokio. Speichern Sie das Meeting als { rrule: "FREQ=WEEKLY;BYDAY=TU", time: "09:00", tz: "America/New_York" }. Der Kalender des Londoner Teilnehmers löst jeden Termin auf: Im Januar ist NY auf EST (UTC−5) und London auf GMT (UTC+0), also liegt das Meeting um 14:00 Londoner Zeit. Im März (nach Beginn der US-Sommerzeit, aber vor Beginn der EU-Sommerzeit) ist NY auf EDT (UTC−4) und London auf GMT, also liegt das Meeting um 13:00 Londoner Zeit – eine Stunde früher verschoben. Im Juni sind beide auf Sommerzeit, NY EDT (UTC−4) und London BST (UTC+1), also liegt das Meeting wieder um 14:00 Londoner Zeit. Tokio (UTC+9, keine Sommerzeit) sieht das Meeting je nach Jahreszeit zwischen 22:00 und 23:00 verschieben. Hätte das Team das Meeting stattdessen als „14:00 UTC“ gespeichert – der NY-Teilnehmer würde erleben, wie die Meeting-Zeit mit der Sommerzeit hin- und herwandert, und die „Dienstag 9 Uhr“-Konvention würde zweimal im Jahr stillschweigend brechen.

Wann und warum es zählt

IANA-Zeitzonen zählen in dem Moment, in dem ein System Datumsangaben über mehr als einen Nutzer, mehr als einen Ort oder mehr als eine Jahreszeit verarbeitet. Der zu vermeidende Fehler bei der Speicherung ist die Verwendung fester Offsets – „Asia/Karachi“ übersteht eine künftige Wiedereinführung der Sommerzeit; „UTC+5“ nicht. Der zu vermeidende Fehler bei der Anzeige ist das Rendern von Zeitstempeln ohne Angabe der Zielzone – ein Backend-Log, das „2026-05-22 14:30“ ohne Zonen-Tag zeigt, ist mehrdeutig und nicht durchsuchbar. Der zu vermeidende Fehler in der Geschäftslogik ist, „+1 Tag“-Arithmetik in UTC statt in Ortszeit rund um Sommerzeitübergänge durchzuführen – „nächster Tag, gleiche Wanduhrzeit“ kann in UTC 23 oder 25 Stunden entfernt sein, je nachdem, ob in jener Nacht die Sommerzeit beginnt. Moderne Datums-/Zeit-Bibliotheken (JavaScripts Temporal-API, Pythons zoneinfo, Javas java.time) handhaben dies korrekt, wenn ihnen IANA-Kennungen gegeben werden; ältere APIs (JavaScripts natives Date, moment.js ohne Zeitzonen-Plugin) erzeugen stillschweigend falsche Antworten. Quelle: RFC 6557 — Procedures for Maintaining the Time Zone Database.

Der IANA-tzdata-Release-Zyklus: tzdata-Releases werden nach Jahr + Kleinbuchstabe versioniert – 2024a, 2024b, 2025a und so weiter. Releases erfolgen bei Bedarf, meist 4- bis 8-mal pro Jahr, immer wenn eine Regierung Sommerzeitregeln oder der UTC-Offset einer Region ändert. Bemerkenswerte jüngere Änderungen: Mexiko schaffte 2022 landesweit die Sommerzeit ab; Russland verwarf und stellte über mehrere Revisionen hinweg die dauerhafte Winterzeit wieder her; der Libanon hatte 2023 wegen eines politischen Streits einen um eine Woche verzögerten Sommerzeitbeginn. Jedes Betriebssystem übernimmt die Änderungen durch routinemäßige Paket-Updates – aber IoT-Geräte und alte Telefone, die sich nicht automatisch aktualisieren, können abdriften, was zum kanonischen „mein Wecker geht eine Stunde falsch“-Problem in der ersten Woche nach einer Sommerzeit-Regeländerung führt.

Warum man Offsets nie direkt speichern sollte: Der häufigste Fehler in Datums-/Zeit-Code ist, „UTC+2“ statt Europe/Istanbul zu speichern. Der Offset erfasst eine zeitpunktbezogene Tatsache über die Zone, aber nicht die Regeln. Führt die Türkei die Sommerzeit wieder ein (sie schaffte sie 2016 ab, doch Regeländerungen sind in der Region häufig), wird jeder Datensatz mit „UTC+2“ über Nacht falsch. Speichern Sie die IANA-Zonenkennung und lassen Sie die Auflösung den korrekten Offset für jeden Zeitstempel berechnen. Verwandt: UTC, Schaltsekunde. Quelle: IANA Time Zone Database.