Skip to content

Data study

Fünfzig Jahre Sommerzeit-Änderungen: eine Tour durch die IANA-tzdata-Historie

Die Sommerzeit sollte eine abgeschlossene Politik sein. Das IANA-tzdata-Changelog zeigt, dass sie es nicht ist — und nicht sein wird.

By Published

Die meisten Softwareentwickler behandeln Sommerzeit-Zeitpläne als statisches Wissen. Sind sie aber nicht. Die IANA-tzdata- Datenbank — die kanonische Quelle für Zeitzonenregeln weltweit — hat seit Jahrzehnten mehrere Updates pro Jahr ausgeliefert. Zwischen 1990 und 2024 verzeichnete die Datenbank Regeländerungen für mindestens 39 verschiedene nationale oder subnationale Entitäten. Dieser Beitrag führt durch die größten Änderungen, warum sie geschahen und was sie über das Design von Scheduling-Systemen lehren.

Was „eine Regeländerung“ bedeutet

IANA tzdata speichert Zeitzonenregeln als Paare aus (Gültigkeitszeitraum, Offset/Sommerzeitverhalten). Eine Regeländerung fügt einen neuen Eintrag hinzu — „ab Datum X beachtet diese Zone keine Sommerzeit mehr“ — und lässt die historischen Regeln intakt. Systeme, die auf akkurates Scheduling angewiesen sind, müssen Updates regelmäßig laden; eines, das einen 2010er Snapshot von tzdata lädt, liefert jede sommerzeitabhängige Berechnung für jede Regeländerung nach 2010 falsch.

Ausgewählte folgenreiche Änderungen

Russland (2011, 2014)

2011 stellte die Russische Föderation dauerhaft auf Sommer- zeit um und schaffte Uhrumstellungen ab. Bis 2014 kehrte sich die Politik um — Russland wechselte dauerhaft zur Standardzeit (Winterzeit). Zwei Regeländerungen in drei Jahren für ein 11-Zeitzonen-Land betrafen jeden russland-orientierten Dienst. Outlook, Exchange-Server und geplante Datenbank-Jobs feuerten in beiden Jahren wellenweise fehlerhaft.

Brasilien (2019)

Brasilien beendete die Sommerzeit Ende 2019, nachdem es sie etwa 80 Jahre lang beachtet hatte. Die Entscheidung erfolgte aus energiepolitischen Gründen — die historisch durch die Sommerzeit erzielten Einsparungen waren erodiert, da sich die Spitzenlastmuster verschoben hatten. Rund 70 Millionen Menschen in den betroffenen südlichen und südöstlichen Bundesstaaten erwachen nun ganzjährig zum selben Offset.

Ägypten (2010–2015, hin und her)

Ägypten schaffte die Sommerzeit 2010 ab, führte sie für die Saison 2014–2015 wieder ein (mit einer bemerkenswerten Aussetzung mitten im Ramadan) und schaffte sie dann erneut ab. Der Fall 2014 ist ein berühmtes Software-Rollout-Lehrstück: Die Ankündigung der Regel- änderung kam so kurz vor dem Vorstell-Datum, dass viele Systeme sie nicht aufnahmen; ägyptische Nutzer sahen auf ihren Telefonen tagelang um 1–2 Stunden falsche Zeiten.

Samoa (2011)

Samoa wechselte von UTC-11 zu UTC+13, indem es den 30.12.2011 vollständig übersprang. Das Land überquerte effektiv die internationale Datumsgrenze an einem Donnerstagmorgen und sprang direkt auf Samstag. Handel und Schifffahrt mit Australien und Neuseeland trieben die Änderung; samoanische Unternehmen hatten zuvor eine 21-stündige Geschäftstag-Diskrepanz mit ihren wichtigsten Handelspartnern.

Türkei / Turkey (2016)

Die Türkei gab die Sommerzeit 2016 auf und fixierte das Land ganzjährig auf UTC+3. Genannte Gründe: fragwürdige Energieeinsparungen, unbeliebte Morgendunkelheit im Winter. Softwareanbieter beeilten sich, Patches vor dem herbstlichen Zurückstell- Datum auszurollen, das es nicht mehr gab.

Marokko (2018+)

Marokko wechselte 2018 zur dauerhaften Sommerzeit (UTC+1 ganzjährig, jedes Jahr während des Ramadan ausgesetzt, wenn das Land für den Monat auf UTC+0 zurückkehrt). Die ramadanbedingte Doppeländerung jedes Jahr ist eine der komplexesten Regeln in IANA tzdata — ihr Datum verschiebt sich um ~11 Tage jährlich relativ zum gregorianischen Kalender.

EU-Sommerzeit-Richtlinie (2018–2021, weiterhin offen)

Die Europäische Kommission schlug 2018 vor, die Sommerzeit in der gesamten EU zu beenden. Das Europäische Parlament stimmte 2019 mit 2021 als Umsetzungsdatum zu. Eine Einigung der Mitgliedstaaten darüber, welche Zeit dauerhaft zu beachten ist (ihre Sommerzeit oder ihre Standardzeit), wurde nie erreicht; die Änderung ist nicht erfolgt. Stand 2026 beachtet die EU weiterhin die Sommerzeit, auch wenn der politische Konsens, sie zu beenden, fortbesteht.

USA: Sunshine Protection Act (2022)

Der US-Senat verabschiedete im März 2022 einstimmig ein Gesetz, um die Sommerzeit dauerhaft zu machen. Das Repräsentantenhaus griff es nicht auf. Das Gesetz wurde 2023 erneut eingebracht und scheiterte abermals. Die USA stellen weiterhin vor und zurück.

Das Mengenproblem

Zählung der wesentlichen Regeländerungen nach Jahrzehnt (Auszug aus der IANA-tzdata-NEWS-Datei):

JahrzehntUngefähre Anzahl wesentlicher Änderungen
1990er~30 (post-sowjetische Republiken, jemenitische Vereinigung usw.)
2000er~50 (EU-Harmonisierung, mehrere afrikanische und südamerikanische Änderungen)
2010er~70 (Russland zweimal, Ägypten mehrfach, Samoa, Türkei, Marokko, Brasilien usw.)
2020–2024~25 (Libanons Chaos 2023, Yukon, kriegsbedingte Anpassungen in der Ukraine)

Der Trend ist ungefähr stetig: 5–10 bedeutsame Regeländerungen pro Jahr weltweit. Ein System, das tzdata nicht jährlich aktualisiert, liegt bei einer 5 Jahre alten Datenbank für ~3–5 % der Weltbevölkerung falsch.

Was das in der Praxis kostet

Drei Kategorien von Störungen, beobachtet in IT- Post-mortems zu Vorfällen mit veralteter tzdata:

  • Kalender und Meetings. Zonenübergreifende Meeting-Einladungen zeigen die falsche Lokalzeit. Der Teilnehmer mit dem veralteten Telefon verpasst den Anruf.
  • Datenbank-Zeitstempel und Reporting.Cron-Jobs feuern eine Stunde zu früh oder zu spät. Tägliche Aggregatberichte schließen Transaktionen über die Phantom-Sommerzeitgrenze ein oder aus. Subtil, aber teuer bei der Finanzabstimmung.
  • API-Rate-Limit-Fenster und geplante Jobs.Alles, was „Mitternacht in Zone X“ definiert, liegt eine Stunde falsch. SaaS-Abrechnung, Log-Rotations- Zeitpläne und ähnliche Backend-Arbeit schlagen still fehl.

Was man dagegen tun kann

  1. Die IANA-Datenbank nutzen, keine Abkürzungen.Speichern Sie Zonen als America/New_York, nicht alsEST. Abkürzungen kodieren keine Regel- änderungen; IANA-Namen tun es.
  2. tzdata aktuell halten. Betriebssysteme liefern tzdata-Updates monatlich oder quartalsweise. Stellen Sie sicher, dass Container, Funktions-Runtimes und gebündelte Apps sie tatsächlich erhalten.
  3. Geplante Ereignisse bei Regeländerung neu rendern.Ein 2024 geplantes Meeting, das sich „jeden Montag um 14 Uhr New Yorker Zeit“ wiederholt, folgt korrekt der Sommerzeit. Ein 2024 geplantes Meeting, das sich „jeden Montag um 14 Uhr EST“ (die Abkürzung) wiederholt, bricht zweimal im Jahr.
  4. Mit adversariellen Daten testen. Die drei Wochen jedes Frühjahr, in denen US- und EU-Sommerzeit-Zeitpläne nicht übereinstimmen, die Daten, an denen ein Land kürzlich seine Regeln geändert hat, die Schaltsekunden-Überlappung, falls vorhanden. Echte Test-Fixtures enthalten diese.

Für praktisches zonenübergreifendes Scheduling nutzen Sie unseren Zeitzonen-Umrechner (nutzt die tzdata des Browsers) und den Meeting- Planer (behandelt Sommerzeit-Diskrepanzen automatisch).

Quellen

IANA tzdata database NEWS file (Eggert et al., 1986–2024); timeanddate.com archivierte Sommerzeit-Politikberichte; Microsoft Daylight Saving Time and Time Zone bulletins; ICAO- Mitteilungen zu luftfahrttechnischen Zeitreferenzen.

Related

Published May 16, 2026