Zeitumstellung in Software: Typische Fehler mit Datum und Uhrzeit
Die Zeitumstellung macht in Software Probleme, weil es eine Stunde im Jahr doppelt gibt und eine gar nicht, und weil ein Tag dann 23 oder 25 Stunden hat. Sie vermeiden die Fehler, indem Sie Zeitpunkte in UTC speichern, erst bei der Anzeige in Ortszeit umrechnen und Termine, Fristen und Cronjobs gezielt für die Umstellungstage testen.
Die nächsten Termine dafür sind die Nacht auf Sonntag, den 25.10.2026, und die Nacht auf den 28.03.2027. Betroffen ist jede individuelle Webanwendung, die Zeiten speichert, mit ihnen rechnet oder Aufgaben plant: Buchungen, Arbeitszeiten, Fristen, Tagesberichte. Weil die Fehler nur an zwei Tagen im Jahr auftreten, oft nachts und am Wochenende, fallen sie lange nicht auf und sind danach schwer nachzustellen.
Das Problem
Die doppelte und die fehlende Stunde: Fehler durch die Zeitumstellung
Zweimal im Jahr gibt es in Deutschland eine Stunde, die Software falsch einordnen kann. Am Sonntag, 25.10.2026, endet die Sommerzeit: Um 3:00 Uhr Sommerzeit springen die Uhren auf 2:00 Uhr Normalzeit zurück. Die Zeit von 2:00 bis 2:59 Uhr gibt es an diesem Tag zweimal. Im Frühjahr ist es umgekehrt, dann fehlt diese Stunde ganz. Grundlage sind eine EU-Richtlinie und die deutsche Sommerzeitverordnung; europaweit wird zum selben Zeitpunkt umgestellt, um 1:00 Uhr UTC.
Daraus entstehen die typischen Zeitumstellungsfehler:
Mehrdeutige Zeiten: „25.10.2026, 2:30 Uhr“ ohne Zeitzonenangabe kann zwei verschiedene Zeitpunkte meinen, die eine Stunde auseinanderliegen.
Zeiten, die es nicht gibt: „28.03.2027, 2:30 Uhr“ existiert in Deutschland nicht. Bibliotheken gehen damit unterschiedlich um; PHP macht daraus zum Beispiel 3:30 Uhr Sommerzeit.
Tage mit 23 oder 25 Stunden: Wer „ein Tag“ als 24 Stunden rechnet, landet am Umstellungstag eine Stunde daneben. Eine Nachtschicht von 22 bis 6 Uhr dauert in der Nacht auf den 25.10. neun Stunden, nicht acht.
Sortierung: Werden Zeiten als Ortszeit ohne Zeitzone gespeichert, sortiert die Datenbank Ereignisse aus der doppelten Stunde falsch.
Grundregel
UTC speichern, lokal anzeigen
Die wichtigste Regel lautet: Zeitpunkte in UTC speichern und erst bei der Anzeige in die Ortszeit des Nutzers umrechnen. UTC kennt keine Zeitumstellung, jede Minute kommt genau einmal vor. Für Ihre Anwendung heißt das: Datenbank, Server und Anwendung rechnen intern in UTC, nur die Oberfläche zeigt Europe/Berlin.
In der Praxis bedeutet das:
Anwendung: In Laravel steht die Zeitzone in config/app.php standardmäßig auf UTC. Lassen Sie sie dort und rechnen Sie erst in der Ausgabe um.
Datenbank: In MySQL rechnet der Typ TIMESTAMP beim Speichern von der Zeitzone der Verbindung in UTC um, DATETIME speichert den Wert ohne Zeitzone. Wer DATETIME nutzt, muss selbst sicherstellen, dass dort immer UTC steht. In PostgreSQL ist timestamp with time zone die passende Wahl.
Zeitzonen benennen: Verwenden Sie Namen aus der IANA-Zeitzonen-Datenbank wie Europe/Berlin, keine festen Versätze wie +01:00. Nur der Name kennt die Regeln für Sommer- und Normalzeit.
Schnittstellen: Zeiten in APIs immer mit Zeitzone übertragen, etwa im Format ISO 8601 mit Z oder Versatz.
Eine Ausnahme gibt es: künftige Termine, die an die Ortszeit gebunden sind. Wenn ein Kunde für den April 2027 einen Termin um 9:00 Uhr bucht, meint er 9:00 Uhr in München, egal welche Regeln dann gelten. Solche Termine speichern Sie als Ortszeit plus Zeitzonenname und rechnen erst bei Bedarf in UTC um. Ändert sich eine Regel, stimmt der Termin trotzdem.
Abläufe
Termine, Fristen und Cronjobs
Termine, Fristen und geplante Aufgaben sind die Stellen, an denen die Zeitumstellung am häufigsten Folgen hat. Hier geht es nicht um Darstellung, sondern um Abläufe, die zur falschen Zeit oder gar nicht laufen.
Wiederkehrende Termine
Ein Termin „jeden Montag um 9:00 Uhr“ muss nach der Umstellung weiter um 9:00 Uhr Ortszeit liegen, nicht um 8:00 oder 10:00 Uhr. Wer die Serie als UTC-Zeitpunkt plus sieben Tage berechnet, verschiebt sie um eine Stunde. Richtig ist, die Regel in Ortszeit mit Zeitzone zu speichern und jedes Vorkommen einzeln umzurechnen. Kalenderformate wie iCalendar sehen dafür eine Zeitzonen-ID vor.
Fristen
Eine Frist in Kalendertagen, etwa „14 Tage ab Zugang“, endet meist zum Tagesende in Ortszeit. Wer 14 mal 24 Stunden auf einen UTC-Zeitpunkt addiert, liegt über eine Umstellung hinweg eine Stunde daneben. Kalendertage rechnen Sie deshalb in Ortszeit, Zeitspannen in Stunden und Minuten in UTC.
Cronjobs und geplante Aufgaben
Läuft der Server in Ortszeit, kann eine Aufgabe um 2:30 Uhr im Oktober zweimal und im März gar nicht ausgeführt werden. Ob das passiert, hängt vom Cron-Dienst ab: Der verbreitete Cron unter Debian etwa holt übersprungene Läufe nach und wiederholt Läufe in der doppelten Stunde nicht, andere Planer verhalten sich anders. Die Laravel-Dokumentation warnt ausdrücklich, dass geplante Aufgaben mit Zeitzone an Umstellungstagen doppelt oder gar nicht laufen können, und rät, Zeitzonen im Scheduler möglichst zu vermeiden.
Unsere Empfehlung: Server und Scheduler in UTC betreiben, nächtliche Aufgaben nicht zwischen 2:00 und 3:00 Uhr Ortszeit legen und jede Aufgabe so bauen, dass ein doppelter Lauf keinen Schaden anrichtet. Diese Eigenschaft heißt Idempotenz: Eine Rechnung, die schon verschickt ist, wird beim zweiten Lauf nicht noch einmal verschickt.
Absichern
Tests für Zeitwechsel
Fehler rund um die Zeitumstellung finden Sie zuverlässig nur mit Tests, die genau diese Tage nachstellen. In Laravel lässt sich die aktuelle Zeit im Test festlegen, etwa mit den Hilfsfunktionen zum Zeitreisen oder mit Carbon::setTestNow(). So prüfen Sie eine Nacht im Oktober, ohne bis Oktober zu warten.
Diese Fälle gehören in jede Testsuite, die mit Zeiten arbeitet:
Eine Eingabe von 2:30 Uhr am letzten Sonntag im Oktober und im März.
Eine Dauer, die über die Umstellung reicht, etwa eine Schicht oder Buchung von 22:00 bis 6:00 Uhr.
Ein Tagesbericht für den Umstellungstag mit 23 oder 25 Stunden.
Ein wiederkehrender Termin, der vor und nach der Umstellung liegt.
Eine Frist, deren Lauf über eine Umstellung geht.
Eine geplante Aufgabe, die zweimal ausgeführt wird.
Hilfreich ist außerdem, die Tests einmal mit einer anderen Zeitzone des Testservers laufen zu lassen. Steckt irgendwo eine versteckte Abhängigkeit von der Serverzeit, fällt sie dann auf. Im Betrieb sieht man diese Fehler selten auf einem Dashboard, weil sie zweimal im Jahr und meist nachts auftreten. Warum Auslastungskurven solche Fälle nicht zeigen, beschreibt der Beitrag Monitoring-Mythen: Was Dashboards nicht zeigen.
Vor jeder Umstellung hilft ein Blick in die Logs der vorigen: Die Einträge vom 29.03.2026 zeigen oft schon, ob die Anwendung im Frühjahr Auffälligkeiten hatte.
Kurz beantwortet
Häufige Fragen
-
In Deutschland endet die Sommerzeit am Sonntag, 25.10.2026: Um 3:00 Uhr werden die Uhren auf 2:00 Uhr zurückgestellt. Die nächste Umstellung auf Sommerzeit folgt nach der geltenden Regel am letzten Sonntag im März, also am 28.03.2027 von 2:00 auf 3:00 Uhr.
-
Sobald eine Webanwendung Zeiten speichert, rechnet oder plant, ist sie betroffen: Buchungen, Arbeitszeiten, Fristen, Berichte pro Tag oder nächtliche Aufgaben. Der Browser des Nutzers rechnet zudem in dessen Zeitzone, der Server oft in einer anderen. Fehler entstehen genau an dieser Grenze.
-
Dann ändern sich die Regeln in der Zeitzonen-Datenbank, die Betriebssysteme, PHP und Datenbanken nutzen. Wer Zeitpunkte in UTC speichert und künftige Termine mit Ortszeit und Zeitzonennamen ablegt, muss nur diese Datenbank aktualisieren. Feste Versätze wie +01:00 im Code wären dann falsch.
Zeitlogik prüfen lassen
Wir prüfen Datum- und Zeitlogik in bestehenden Anwendungen und bauen Tests für die Umstellungstage.
Nachweise
Quellen und Stand
Geprüft am 02.11.2026: Termine der Zeitumstellung nach Richtlinie 2000/84/EG und Sommerzeitverordnung, Verhalten von PHP, MySQL, PostgreSQL, Laravel und Debian-Cron laut Dokumentation.
Artikel teilen