Zeitzonen in Webanwendungen: Zeitumstellung, Termine und Berichte

Falsch behandelte Zeitzonen in einer Webanwendung fallen vor allem bei der Zeitumstellung auf: Eine Erinnerung kommt eine Stunde zu früh, ein Serientermin verschiebt sich nach der Umstellung auf die Sommerzeit, und der Tagesbericht für den Tag der Umstellung passt nicht zur Buchhaltung. Die Lösung ist keine einzelne Servereinstellung, sondern eine klare Regel für jede Art von Zeitangabe. Speichern Sie Zeitpunkte in UTC, künftige, in Ortszeit vereinbarte Termine als Datum, Uhrzeit und Zeitzonennamen, zum Beispiel Europe/Bratislava, Daten ohne Uhrzeit als Datum und Wiederholungen als Regel mit Zeitzone. Testen Sie anschließend gezielt die Tage, an denen die Uhr umgestellt wird.

Das betrifft nicht nur Unternehmen mit Kunden im Ausland. Ein Buchungssystem, die Planung von Serviceeinsätzen oder ein nächtlicher Export in die Buchhaltung genügen. Auch in der Slowakei hat ein Tag im Jahr 23 Stunden und einer 25.

Warum bei der Zeitumstellung eine Stunde fehlt oder doppelt vorkommt

In der Zeitzone Europe/Bratislava werden die Uhren im Frühjahr von 2:00 auf 3:00 Uhr vorgestellt, die Ortszeit 2:30 Uhr gibt es an diesem Tag also nicht. Im Herbst werden sie von 3:00 auf 2:00 Uhr zurückgestellt, und 2:30 Uhr kommt zweimal vor: zuerst mit einem UTC-Versatz von +02:00, dann mit +01:00. Nach den aktuellen Regeln fällt die nächste Umstellung im Frühjahr auf den 28. März 2027 und die im Herbst auf den 31. Oktober 2027.

Diese Regeln legen nicht Programmierer fest. Sie werden in der Zeitzonendatenbank der IANA gepflegt, auch bekannt als tz oder zoneinfo. Laut IANA wird sie regelmäßig aktualisiert, um Änderungen staatlicher Stellen an Zeitzonengrenzen, UTC-Versätzen und Sommerzeitregeln abzubilden, und Endnutzer erhalten die Aktualisierungen in der Regel über Software- und Betriebssystemupdates. Eine Änderung kann kurz vor dem Stichtag kommen: Das Release 2026f vom 27. Oktober 2026 hielt fest, dass Kuba am 1. November 2026 nicht auf Normalzeit zurückstellt.

Entscheidend ist die Unterscheidung zwischen zwei Arten von Zeit. Ein Zeitpunkt ist ein Punkt auf der Zeitachse, etwa der Eingang einer Zahlung oder der Versand einer E-Mail, und lässt sich eindeutig in UTC festhalten. Ein lokaler Termin ist eine Vereinbarung zwischen Menschen, etwa ein Serviceeinsatz am Dienstag um 9:00 Uhr in Košice. Sein Verhältnis zu UTC bestimmen die Zeitzonenregeln, die am Tag des Termins gelten, nicht die am Tag der Erfassung.

Beispiel: Buchungen bei einem Serviceunternehmen

Ein illustratives Beispiel, kein konkreter Kundenfall. Ein Serviceunternehmen plant in einer Webanwendung die Einsätze seiner Techniker, auch am Wochenende. Im Januar bucht ein Kunde eine regelmäßige Kontrolle jeden Dienstag um 9:00 Uhr. Die Anwendung schickt 24 Stunden vor dem Termin eine Erinnerung, exportiert nachts abgeschlossene Aufträge in die Buchhaltung und sendet dem Leiter morgens eine Übersicht der Umsätze des Vortags.

Beim Speichern hat der Entwickler den Termin in UTC umgerechnet: 9:00 Uhr im Januar entspricht 8:00 UTC. Nach der Umstellung auf die Sommerzeit plant die Anwendung weiterhin 8:00 UTC, das ist jetzt aber 10:00 Uhr Ortszeit. Der Techniker kommt eine Stunde später, als der Kunde erwartet.

Andere Fehler fallen weniger auf. Eine Erinnerung „24 Stunden vorher“ für einen Termin am Sonntag, dem 28. März 2027, um 9:00 Uhr geht am Samstag um 8:00 Uhr hinaus, weil zwischen denselben Uhrzeiten dieser beiden Tage nur 23 Stunden vergehen. Ein für 2:30 Uhr geplanter nächtlicher Export läuft in der Frühjahrsnacht womöglich gar nicht und in der Herbstnacht womöglich zweimal, je nachdem, wie sich der Scheduler verhält. Und wenn der Bericht für „gestern“ den Tag von Mitternacht bis Mitternacht UTC rechnet, beginnt er im Winter um 1:00 Uhr und im Sommer um 2:00 Uhr slowakischer Zeit.

Die Korrektur bedeutet nicht, die ganze Anwendung neu zu schreiben. Der Serientermin wird als Regel „jeden Dienstag um 9:00 Uhr, Europe/Bratislava“ gespeichert, das Unternehmen entscheidet, ob eine Erinnerung genau 24 Stunden oder einen Tag vorher zur gleichen Uhrzeit bedeutet, der Export wird aus der nächtlichen Umstellungsstunde verlegt, und der Bericht wird nach dem slowakischen Kalendertag berechnet.

Wie Sie die einzelnen Arten von Zeitangaben speichern

Die Tabelle dient sowohl als Vorgabe für den Entwickler als auch zur Prüfung einer bestehenden Anwendung. Jede Spalte in der Datenbank und jedes Feld in der API sollte genau einer Zeile zugeordnet sein.

Art der Angabe	Wie speichern	Beispiel
Zeitpunkt eines Ereignisses	Ein Punkt auf der Zeitachse in UTC	Zahlungseingang, Anmeldung, Eintrag im Audit-Log
Künftiger lokaler Termin	Lokales Datum und lokale Uhrzeit plus Zeitzonenname; UTC nur als abgeleiteter Wert	Serviceeinsatz am 6. April 2027 um 9:00 Uhr, Europe/Bratislava
Serientermin	Wiederholungsregel, lokale Startzeit und Zeitzone	Jeden Dienstag um 9:00 Uhr
Datum ohne Uhrzeit	Nur das Datum, ohne Uhrzeit und ohne Zeitzone	Fälligkeit einer Rechnung, Urlaubstag
Zeit, die an eine Person und nicht an einen Ort gebunden ist	Ortszeit ohne Zeitzone, ausdrücklich gekennzeichnet	Tägliche Benachrichtigung um 8:00 Uhr dort, wo sich der Nutzer gerade aufhält
Geschäftstag in Berichten	Datum und Zeitzone des Unternehmens; die Tagesgrenzen werden in UTC umgerechnet	Umsatz am 25. Oktober 2026, einem Tag mit 25 Stunden

Achten Sie darauf, was die Datenbank tut. Laut der PostgreSQL-Dokumentation wird ein Wert vom Typ timestamp with time zone intern in UTC gespeichert, und die ursprünglich angegebene Zeitzone wird nicht beibehalten. Enthält die Eingabe keine Zeitzone, nimmt die Datenbank die Zone aus der Einstellung TimeZone an und rechnet die Zeit bei der Ausgabe in die aktuell eingestellte Zone um. Für Zeitpunkte ist das richtig, für künftige lokale Termine brauchen Sie den Zeitzonennamen jedoch in einer eigenen Spalte.

Für personengebundene Zeit kennt der Kalenderstandard iCalendar (RFC 5545) die sogenannte gleitende Zeit. Sie steht für dieselbe Uhrzeit, unabhängig davon, in welcher Zeitzone sich die Person gerade befindet. Verwenden Sie sie nur, wenn das beabsichtigt ist, und nicht als Ersatz für eine fehlende Zeitzone.

Einführung in einer bestehenden Anwendung

1. Erfassen Sie alle Zeitangaben

Gehen Sie Datenbankspalten, API-Felder, Importe, Exporte, geplante Jobs und Berichte durch. Notieren Sie zu jeder Angabe ihre Art laut Tabelle und ihre Herkunft. Markieren Sie unklare Fälle, etwa einen Termin ohne gespeicherte Zeitzone, zur Ergänzung.

2. Speichern Sie den Zeitzonennamen, keinen festen Versatz

Speichern Sie bei Terminen, Standorten und Nutzern den IANA-Zeitzonennamen, zum Beispiel Europe/Bratislava. Ein fester Versatz von +01:00 gilt nur einen Teil des Jahres. Der Standard RFC 9557 rät dringend davon ab, feste Versätze statt einer Zeitzone zu verwenden: Ein aus einem Januarwert übernommener Versatz würde nach dem Addieren von sechs Monaten zu einem Ergebnis führen, das um eine Stunde abweicht.

3. Übertragen Sie die Zeit in der API eindeutig

Verwenden Sie in der API das Format nach RFC 3339 mit UTC-Versatz, zum Beispiel 2027-04-06T09:00:00+02:00. RFC 9557 erweitert dieses Format um ein Suffix mit dem Zeitzonennamen, zum Beispiel 2027-04-06T09:00:00+02:00[Europe/Bratislava]. Bei lokalen Terminen erhält die Gegenseite so den Zeitpunkt und die Zeitzone, nach der sie die Zeit weiter umrechnen soll. Versteht sie das Suffix nicht, senden Sie den Zeitzonennamen in einem eigenen Feld. Nach demselben Standard können Sender und Empfänger unterschiedliche Versionen der Zeitzonendatenbank verwenden, deshalb muss die Integration auch mit einem unbekannten Zeitzonennamen umgehen können.

4. Zeigen Sie die Zeit in der richtigen Zeitzone an

Formatiert die Anwendung die Zeit im Browser mit Intl.DateTimeFormat, akzeptiert die Option timeZone laut MDN-Dokumentation einen IANA-Zeitzonennamen; ohne sie wird die Zeitzone der Umgebung verwendet, in der der Code läuft. Ein Kunde, dessen Telefon auf eine andere Zeitzone eingestellt ist, etwa im Urlaub, sähe den Termin des slowakischen Servicebetriebs also verschoben. Legen Sie fest, ob ein Termin in der Zeitzone des Einsatzorts oder des Nutzers angezeigt wird, und geben Sie die Zeitzone neben der Uhrzeit an.

5. Legen Sie Regeln für nicht existierende und doppelte Uhrzeiten fest

Der Standard iCalendar hat dafür klare Regeln: Kommt eine Ortszeit zweimal vor, gilt ihr erstes Auftreten; existiert sie nicht, wird sie mit dem Versatz interpretiert, der vor der Umstellung galt. Ein Termin am 28. März 2027 um 2:30 Uhr fiele damit auf 3:30 Uhr Sommerzeit. Der Standard weist auch darauf hin, dass eine Wiederholungsregel ein ungültiges Datum wie den 30. Februar oder eine nicht existierende Ortszeit erzeugen kann. Wählen Sie ein Verhalten, halten Sie es in der Vorgabe fest, und bieten Sie solche Uhrzeiten im Buchungsformular am besten gar nicht erst an.

6. Passen Sie geplante Jobs und Berichte an

Planen Sie technische Jobs wie Backups oder Exporte in UTC oder außerhalb der nächtlichen Umstellungsstunde, und gestalten Sie sie so, dass ein wiederholter Lauf keine Duplikate erzeugt. Jobs, die an die Ortszeit gebunden sind, etwa den morgendlichen Versand, planen Sie nach Zeitzone. Berechnen Sie einen Tagesbericht von lokaler Mitternacht bis zur nächsten lokalen Mitternacht, jeweils in UTC umgerechnet, und teilen Sie den Stundendurchschnitt nicht durch eine feste 24.

7. Aktualisieren Sie die Zeitzonendatenbank und testen Sie die Umstellungstage

Zeitzonendaten kommen über das Betriebssystem, die Laufzeitumgebung der Programmiersprache, Bibliotheken und die Datenbank; nehmen Sie ihre Aktualisierung daher in die regelmäßige Wartung auf. Rechnen Sie nach einer Regeländerung die abgeleiteten UTC-Werte künftiger Termine neu. Führen Sie automatisierte Tests mit festen Daten aus, etwa dem 28. März und dem 31. Oktober 2027, und mit unterschiedlichen Zeitzonen auf dem Server und im Browser.

Vor- und Nachteile der einzelnen Ansätze

• Alles in UTC: einfaches Vergleichen und Sortieren von Zeitpunkten, aber Serientermine verschieben sich bei der Zeitumstellung und künftige Termine auch bei einer Änderung der Zeitzonenregeln.
• Alles in der Ortszeit des Servers: bequem für ein Unternehmen in einem Land, aber mehrdeutig in der Herbstnacht und anfällig, wenn der Server in eine andere Zeitzone umzieht.
• Ortszeit, Zeitzone und abgeleitetes UTC: korrekt für Termine, erfordert aber mehr Spalten, klare Regeln und eine Neuberechnung nach einem Update der Zeitzonendatenbank.
• Anzeige in der Zeitzone des Nutzers: natürlich bei Online-Meetings, verwirrend bei Dienstleistungen an einem bestimmten Ort, wo die Zeitzone des Einsatzorts sinnvoll ist.

Für die meisten Geschäftsanwendungen empfehlen wir eine Kombination: Zeitpunkte in UTC, Termine in Ortszeit mit Zeitzone und die Anzeige in der Zeitzone des Einsatzorts mit klar angegebener Zeitzone.

Häufige Fehler

• Ein Serientermin, der als einzelne Zeit in UTC gespeichert ist.
• Ein fester Versatz +01:00 oder die Zeitzone des Servers statt eines Zeitzonennamens beim Termin.
• Die Annahme, dass ein Tag immer 24 Stunden hat, bei Erinnerungen, Fristen und Berichten.
• Formatierung der Zeit im Browser ohne festgelegte Zeitzone.
• Nächtliche Jobs, die zwischen 2:00 und 3:00 Uhr Ortszeit geplant sind.
• Eine veraltete Zeitzonendatenbank auf dem Server, im Container oder in der Anwendung.
• Tests, die nur in einer Zeitzone und nie am Tag der Zeitumstellung laufen.

Checkliste für Vorgabe und Abnahme

• Jede Zeitangabe hat eine festgelegte Art: Zeitpunkt, lokaler Termin, Wiederholung, Datum oder Geschäftstag.
• Für Termine und Standorte ist ein IANA-Zeitzonenname gespeichert.
• Die API sendet die Zeit mit UTC-Versatz und bei Terminen auch den Zeitzonennamen.
• Die Oberfläche zeigt, in welcher Zeitzone eine Uhrzeit angegeben ist.
• Das Verhalten bei nicht existierenden und doppelten Uhrzeiten sowie bei Wiederholungen ist dokumentiert und getestet.
• Berichte berechnen den Geschäftstag in der Zeitzone des Unternehmens und kommen mit Tagen von 23 und 25 Stunden zurecht.
• Das Update der Zeitzonendatenbank gehört zur Wartung, danach werden künftige Termine neu berechnet.

Häufige Fragen

Reicht es, alle Zeiten in UTC zu speichern?

Für Zeitpunkte ja, für künftige, in Ortszeit vereinbarte Termine nein. Laut RFC 9557 können sich die Regeln einer benannten Zeitzone ändern, und es gelten die Regeln, die zum Zeitpunkt der Verarbeitung aktuell sind. Speichern Sie daher die Ortszeit mit Zeitzone und leiten Sie UTC daraus ab.

Müssen wir uns darum kümmern, wenn wir nur inländische Kunden haben?

Ja. Die Zeitumstellung betrifft auch eine einzige Zeitzone, und Server, Datenbank oder das Telefon eines Kunden können auf eine andere Zeitzone eingestellt sein als das Unternehmen. Fehler zeigen sich daher womöglich erst in der Nacht der Zeitumstellung oder in den Wochen danach.

Was passiert mit einem Termin in einer Stunde, die es nicht gibt?

Das Buchungsformular sollte sie nicht anbieten. Entsteht ein solcher Termin durch einen Import oder eine Wiederholung, wenden Sie die festgelegte Regel an, etwa die Verschiebung auf 3:30 Uhr nach iCalendar, und legen Sie die betroffenen Buchungen dem Disponenten zur Prüfung vor.

Wie oft ändert sich die Zeitzonendatenbank?

Laufend, sobald Staaten Zeitzonengrenzen, den UTC-Versatz oder die Sommerzeitregeln ändern. Eine Änderung kann nur wenige Tage vor ihrem Inkrafttreten erscheinen, wie das Release 2026f gezeigt hat. Aktualisieren Sie sie daher zusammen mit den regulären Systemupdates und nicht erst, wenn ein Problem auftritt.

Möchten Sie die Zeitangaben in Ihrer Anwendung prüfen lassen?

Arbeitet Ihre Anwendung mit Buchungen, Planung, Erinnerungen oder Tagesberichten, unterstützen wir Sie bei der Bestandsaufnahme der Zeitangaben, der Anpassung des Datenmodells, bei Tests für die Tage der Zeitumstellung und bei der Korrektur bereits gespeicherter Termine. Mehr über unsere Arbeit erfahren Sie auf der Seite individuelle Webanwendungen.

Schicken Sie uns eine kurze Beschreibung, welche Termine oder Berichte sich verschieben und wann das passiert ist. Weitere Artikel zur Entwicklung und zum Betrieb von Anwendungen finden Sie in unserem Blog.

Quellen

• Time Zones – IANA, Zeitzonendatenbank
• RFC 9557: Date and Time on the Internet: Timestamps with Additional Information – IETF
• RFC 5545: Internet Calendaring and Scheduling Core Object Specification (iCalendar) – IETF
• Intl.DateTimeFormat() constructor – MDN Web Docs
• Date/Time Types – PostgreSQL-Dokumentation