Zeitumstellung im Monitoring: die Stunde, die zweimal kommt

Was in der Nacht zum 25. Oktober 2026 geschieht

Die Regel steht auf zwei Ebenen. Europäisch legt die Richtlinie 2000/84/EG fest, dass die Sommerzeit in jedem Mitgliedstaat am letzten Sonntag im Oktober um 1 Uhr Weltzeit endet und am letzten Sonntag im März um 1 Uhr Weltzeit beginnt (Richtlinie 2000/84/EG). Der Bezug auf die Weltzeit ist der eigentliche Kern der Regelung: Die Umstellung geschieht in allen Mitgliedstaaten im selben Augenblick, nur die Ortszeit, die dabei angezeigt wird, unterscheidet sich je Zeitzone. National setzt die Sommerzeitverordnung das um. Sie beschreibt den Herbsttermin so, dass die Stundenzählung um eine Stunde von 3 Uhr auf 2 Uhr zurückgestellt wird und die Stunde von 2 Uhr bis 3 Uhr dabei zweimal erscheint (Sommerzeitverordnung). Für die beiden Stunden gibt es sogar amtliche Bezeichnungen: Die erste heißt 2A und liegt noch in der Sommerzeit, die zweite heißt 2B und liegt schon in der Normalzeit (Sommerzeitverordnung). 2026 fällt der letzte Sonntag im Oktober auf den 25.; die doppelte Stunde beginnt um 00:00 Uhr Weltzeit und endet um 02:00 Uhr Weltzeit.

Für ein System ist das eine Frage der Eindeutigkeit. Ein Zeitstempel in Weltzeit bezeichnet einen Zeitpunkt; ein Zeitstempel in Ortszeit bezeichnet eine Beschriftung, und diese Beschriftung trägt in dieser Nacht zwei Zeitpunkte. RFC 9557 formuliert das für die Umrechnung in beide Richtungen: Lokale Zeitangaben können null oder mehrere mögliche Zeitpunkte haben, weil in der Nähe eine Sommerzeitumstellung oder eine andere Änderung des UTC-Abstands liegt (RFC 9557). Wer eine solche Angabe ohne Abstand speichert, verliert eine Information, die sich später nicht mehr rekonstruieren lässt. Aus 02:30 Uhr wird dann kein Zeitpunkt, sondern eine Menge aus zwei Zeitpunkten, und weder Sortierung noch Differenz noch Dauerberechnung führen darüber hinweg zu einem verlässlichen Ergebnis.

• 25. Oktober 2026: An diesem Tag endet die Sommerzeit; die Richtlinie legt dafür den letzten Sonntag im Oktober um 1 Uhr Weltzeit fest (Richtlinie 2000/84/EG).
• Zweimal 2 Uhr: Die Stunde von 2 Uhr bis 3 Uhr erscheint zweimal; die erste trägt die amtliche Bezeichnung 2A, die zweite 2B (Sommerzeitverordnung).
• 169 Stunden hat die Woche vom 19. bis zum 26. Oktober 2026 statt der üblichen 168; die Woche der Frühjahrsumstellung hat entsprechend 167. Beide Zahlen sind die rechnerische Folge der doppelten beziehungsweise fehlenden Stunde und stehen nicht im Verordnungstext.
• 4,6 Millionen Rückmeldungen gingen bei der öffentlichen Konsultation der Europäischen Kommission zur Sommerzeit im Sommer 2018 ein (Europäische Kommission, 2018).
• 84 Prozent der Teilnehmenden sprachen sich dabei für die Abschaffung der halbjährlichen Zeitumstellung aus (Europäische Kommission, 2018).
• Drei Fassungen der IANA-Zeitzonendatenbank erschienen allein im Jahr 2026: 2026a im März, 2026b im April und 2026c im Juli (IANA).

Für die Planung zählt, was in Kraft ist. Die Sommerzeitverordnung führt die mitteleuropäische Sommerzeit ab dem Jahr 2002 auf unbestimmte Zeit ein (Sommerzeitverordnung). Über die Abschaffung wird seit Jahren diskutiert: Die Europäische Kommission führte im Sommer 2018 eine Online-Konsultation durch, erhielt 4,6 Millionen Rückmeldungen und berichtete, dass sich 84 Prozent der Teilnehmenden für ein Ende der halbjährlichen Umstellung aussprachen (Europäische Kommission, 2018); mehr als drei Viertel, nämlich 76 Prozent, bewerteten die Umstellung als negative Erfahrung (Europäische Kommission, 2018). Ein Vorschlag ging danach an Parlament und Rat. Für den Betrieb ändert das vorerst nichts. Solange die geltende Regelung nicht ersetzt ist, findet die Umstellung statt, und Systeme, die sie nicht sauber abbilden, fallen weiterhin an denselben Stellen auf.

UTC speichern, Ortszeit anzeigen

Die Regel ist alt und trägt weiterhin: Zeitpunkte werden in Weltzeit gespeichert und erst bei der Anzeige in die Zeitzone des Betrachters umgerechnet. Sie klingt banal und scheitert in der Praxis selten am Vorsatz, sondern meist an einer einzelnen Spalte, die jemand als lokale Zeit angelegt hat, weil die Anzeige damit einfacher war. Eine Datenbankspalte ohne Zeitzonenangabe speichert eine Beschriftung, keinen Zeitpunkt. Ein Protokollformat ohne Abstand tut dasselbe. Das ganze Jahr über fällt das nicht auf, weil die Zuordnung zwischen Beschriftung und Zeitpunkt eindeutig ist. In der Nacht der Rückstellung ist sie es nicht mehr, und im Frühjahr fehlt umgekehrt eine Stunde, für die es überhaupt keine gültige Beschriftung gibt.

Die Folgen sind unspektakulär und deshalb schwer zu finden. Zwei Messwerte tragen denselben Zeitstempel und liegen doch eine Stunde auseinander. Eine Auswertung, die nach Zeitstempel gruppiert, legt zwei Stunden in denselben Eimer und zeigt für 02:00 Uhr die doppelte Zahl an Ereignissen. Eine Abfrage mit einem Zeitfenster liefert Datensätze doppelt oder gar nicht, je nachdem, wie die Grenzen gesetzt sind. Ein Auftrag, der den zuletzt verarbeiteten Zeitstempel als Marke speichert, verarbeitet die zweite Stunde erneut oder überspringt sie. Wie lange solche Schäden unbemerkt bleiben, bis jemand gezielt hinsieht, zeigt für einen verwandten Fall der Beitrag Zeichenkodierung nach einer Migration prüfen.

Cron in der doppelten Stunde

Zeitgesteuerte Aufträge sind die Stelle, an der die doppelte Stunde am schnellsten sichtbar wird. Die Handbuchseite von cron unter Debian beschreibt das Verhalten ausdrücklich: Für Uhrumstellungen von weniger als drei Stunden gelten Sonderregeln, wie sie zu Beginn und Ende der Sommerzeit auftreten (Debian, cron(8)). Läuft die Uhr vor, werden Aufträge aus der übersprungenen Zeit kurz nach der Umstellung nachgeholt. Läuft sie zurück, werden Aufträge aus der wiederholten Zeit nicht ein zweites Mal ausgeführt. Betroffen sind dabei nur Aufträge zu einer bestimmten Uhrzeit; Aufträge mit Platzhalter in Stunde oder Minute folgen der neuen Zeit unmittelbar. Umstellungen von mehr als drei Stunden wertet cron dagegen als Korrektur der Uhr und nutzt die neue Zeit sofort (Debian, cron(8)). Andere Zeitgeber verhalten sich anders, und genau das ist der Punkt: Das Verhalten ist eine Eigenschaft des Werkzeugs, keine Eigenschaft der Zeit.

• Aufträge um 02:30 Uhr Ortszeit laufen im Herbst in der Regel einmal und im Frühjahr kurz nach der Umstellung nach, statt zu ihrer eigentlichen Zeit.
• Aufträge mit Platzhalter in der Stundenangabe folgen der neuen Zeit unmittelbar und laufen in der doppelten Stunde entsprechend ein zweites Mal.
• Aufträge in Weltzeit sind von beidem unberührt; ein Zeitgeber, der in UTC plant, kennt weder eine doppelte noch eine fehlende Stunde.
• Aufträge mit Sperre über Datei oder Datensatz laufen in der doppelten Stunde in die eigene Sperre, wenn der Schlüssel die Ortszeit enthält.

Die Antwort darauf ist kein Kalendereintrag, sondern eine Rückmeldung. Ein Auftrag, der nach jedem Lauf ein Signal sendet, macht den ausgefallenen Lauf sichtbar, ohne dass jemand am Montag Protokolle durchsucht. Wie das im Alltag aussieht, beschreibt der Beitrag Heartbeat-Monitoring für Cron Jobs; die technische Seite steht unter Heartbeats. Für die Nacht der Umstellung lohnt sich eine Ergänzung: Das erwartete Zeitfenster bekommt für diese eine Nacht eine Stunde mehr Spielraum, damit der verschobene Lauf keinen Fehlalarm auslöst und der ausgefallene trotzdem auffällt.

Wartungsfenster, das über die Umstellung reicht

Ein Wartungsfenster wird in der Regel in Ortszeit vereinbart, weil die Menschen, die es betrifft, in Ortszeit leben. Gerechnet wird es aber in realer Dauer. Ein Fenster von 2 bis 4 Uhr Ortszeit dauert im Herbst drei Stunden und im Frühjahr eine. Wer die Dauer im Vertrag oder in der Ankündigung nennt, sollte das an diesen beiden Tagen nachrechnen, und wer die Unterdrückung von Alarmen daran hängt, erst recht: Eine Unterdrückung, die eine Stunde zu früh endet, erzeugt Alarme mitten in der Arbeit; eine, die eine Stunde zu spät endet, verdeckt eine echte Störung. Welche Fehler dabei typischerweise auftreten, ist im Beitrag Wartungsfenster im Monitoring beschrieben.

Die Tabelle enthält keine Sammlung von Ausnahmen, die man sich merken müsste, sondern eine einzige Ursache in mehreren Erscheinungsformen: Ortszeit ist eine Beschriftung, Weltzeit ist eine Achse. Alles, was in Beschriftungen rechnet, verliert an zwei Tagen im Jahr eine Stunde oder erfindet eine. Praktisch heißt das: Fenster, Fristen und Schwellen werden als Dauer definiert und in Ortszeit angezeigt, nicht umgekehrt.

Was das Monitoring in dieser Nacht braucht

Die Umstellung ist ein planbares Ereignis, und planbare Ereignisse gehören vorher in die Überwachung und nicht nachher in die Ursachenanalyse. Vier Punkte tragen erfahrungsgemäß den größten Teil der Arbeit.

Dazu kommt eine organisatorische Kleinigkeit mit großer Wirkung: Die Zeitzone der Auswertung sollte dieselbe sein wie die Zeitzone, in der die Bereitschaft arbeitet und in der Kunden ihre Berichte lesen. Wenn ein Bericht in Weltzeit gerechnet und in Ortszeit besprochen wird, entstehen Diskussionen über Stunden, die niemand gemessen hat. Steht die Zeitzone dagegen sichtbar in der Ausgabe, ist die Frage in einem Satz geklärt.

Vergleichszeiträume in Berichten

Ein Wochenbericht vergleicht in der Regel sieben Tage mit den sieben Tagen davor. In der Woche der Rückstellung sind das rechnerisch 169 Stunden gegen 168, in der Woche der Vorstellung 167 gegen 168. Der Unterschied ist klein und trotzdem sichtbar, sobald absolute Zahlen verglichen werden: Seitenaufrufe, Anfragen, Ausfallminuten. Bei einer Verfügbarkeitszahl wirkt er in die andere Richtung, weil sich der Nenner ändert und dieselbe Ausfalldauer damit einen etwas kleineren Anteil ergibt. Ein halbes Prozent Abweichung reicht, um eine Diskussion auszulösen, die niemand führen möchte, während sie sich mit einer Zeile in der Berichtsfußzeile vermeiden lässt.

// Wochenvergleich über die Rückstellung hinweg, Europe/Berlin
const start = new Date('2026-10-19T00:00:00+02:00'); // Montag, Sommerzeit
const ende  = new Date('2026-10-26T00:00:00+01:00'); // Montag, Normalzeit

console.log((ende - start) / 3600000); // 169

// Naive Rechnung: sieben mal vierundzwanzig Stunden addiert
const naiv = new Date(start.getTime() + 7 * 24 * 3600000);
console.log(naiv.toISOString());       // 2026-10-25T22:00:00.000Z

// Ortszeit dazu: 2026-10-25 23:00 MEZ, also eine Stunde vor Wochenschluss.
// Der letzte Messwert der Woche fällt damit aus dem Bericht heraus.

Der Ausschnitt zeigt den Fehler in seiner häufigsten Form: Sieben mal vierundzwanzig Stunden auf einen Zeitpunkt addiert ergibt im Herbst einen Endpunkt, der eine Stunde vor dem eigentlichen Wochenschluss liegt. Wer Zeiträume über Kalendergrenzen bildet, rechnet deshalb mit der Zeitzone und nicht mit einem festen Abstand in Millisekunden. Das gilt für Wochen- und Monatsberichte gleichermaßen, und es gilt für jede Kennzahl, die einen Vorzeitraum nennt. In Berichten und auf der Statusseite sollte die zugrunde gelegte Zeitzone deshalb im Dokument selbst stehen, nicht nur in der Einstellung, aus der es erzeugt wurde.

Eine Zeitangabe ohne Zeitzone ist keine Zeitangabe, sondern eine Vermutung mit vier Ziffern.

— XICTRAQ

Bereitschaft: die Schicht, die eine Stunde länger ist

Wer eine Rufbereitschaft von 22 bis 6 Uhr Ortszeit besetzt, besetzt im Herbst neun und im Frühjahr sieben Stunden. Das ist keine akademische Feinheit. Die neunte Stunde liegt in der Nacht, in der ohnehin mehr passiert, und sie fällt in vielen Plänen unter den Tisch, weil der Kalender in Ortszeit rechnet und die Vergütung an der geplanten Dauer hängt. Wie sich eine tragfähige Rotation aufbauen lässt, ohne dass einzelne Personen die Last tragen, steht im Beitrag On-Call-Rotation aufbauen.

• Übergaben liegen auf 21:45 Uhr oder 06:15 Uhr Ortszeit, damit keine Übergabe in die doppelte Stunde fällt.
• Eskalationsfristen werden in Minuten geführt und nicht als Uhrzeit; eine Frist bis 03:00 Uhr Ortszeit ist in dieser Nacht mehrdeutig.
• Der Dienstplan weist die reale Dauer aus, damit Vergütung und Ruhezeit zur tatsächlichen Schicht passen.
• Die Benachrichtigung trägt Zeitpunkt, Zeitzone und Abstand, damit die Reihenfolge zweier Meldungen aus derselben Ortsstunde ablesbar bleibt.

tzdata: das Paket, das altert

Die Regeln selbst liegen nicht im Code, sondern in einer Datenbank. Die IANA-Zeitzonendatenbank enthält die Geschichte der Ortszeit für viele Regionen und wird laufend an politische Entscheidungen über Zeitzonengrenzen, UTC-Abstände und Sommerzeitregeln angepasst (IANA). Wie oft das geschieht, zeigt die Veröffentlichungsliste: Allein im Jahr 2026 erschienen drei Fassungen der IANA-Zeitzonendatenbank, nämlich 2026a im März, 2026b im April und 2026c im Juli (IANA). Die Fassung 2026c vom 8. Juli 2026 enthält unter anderem den Wechsel Marokkos auf einen dauerhaften Abstand von +00 zum 20. September 2026 (IANA). Ein System mit einem alten Paket rechnet solche Änderungen falsch, ohne dass eine Fehlermeldung entsteht: Es hat eine Regel, sie ist nur nicht mehr die geltende.

Die drei Aufrufe beantworten drei verschiedene Fragen. Der erste zeigt, welche Umstellungspunkte das System für 2026 kennt; steht dort für den 25. Oktober kein Übergang, ist das Paket veraltet. Der zweite und der dritte zeigen dieselbe Ortszeit für zwei Zeitpunkte, die eine Stunde auseinanderliegen, einmal mit der Kennung CEST und einmal mit CET. Die Prüfung dauert eine Minute und ist auf jedem System sinnvoll, das Zeitangaben verarbeitet, auch auf denen, die Daten nur weiterreichen. Schnittstellen mit eigenen Zeitangaben fallen dabei besonders auf: Eine Antwort mit Ortszeit ohne Abstand ist in dieser Nacht nicht eindeutig, und wenn eine Schnittstelle abgekündigt wird, hängt die Frist an derselben Rechnung, wie der Beitrag Sunset- und Deprecation-Kopfzeilen überwachen zeigt.

Die andere Richtung: die Stunde, die fehlt

Im Frühjahr dreht sich der Fall um. Die Sommerzeitverordnung beschreibt den Beginn so, dass die Stundenzählung um eine Stunde von 2 Uhr auf 3 Uhr vorgestellt wird (Sommerzeitverordnung). Die Ortszeiten zwischen 02:00 und 03:00 Uhr gibt es an diesem Tag nicht. Eine Anwendung, die eine solche Angabe entgegennimmt, hat drei vertretbare Möglichkeiten: sie zurückweisen, sie auf 03:00 Uhr verschieben oder sie als 01:00 Uhr Weltzeit auslegen. Alle drei sind vertretbar, solange die Wahl bewusst getroffen und dokumentiert ist. Teuer wird der vierte Fall: eine Bibliothek, die still die eine Auslegung wählt, und eine zweite Bibliothek im selben System, die ebenso still die andere wählt.

Für den Betrieb ist die fehlende Stunde die harmlosere von beiden, weil sie laut ist: Ein Auftrag läuft nicht, ein Termin lässt sich nicht speichern, eine Umrechnung wirft eine Ausnahme. Die doppelte Stunde ist die teurere, weil sie leise ist: Alles läuft, nur die Daten stimmen nicht. Deshalb lohnt sich im Herbst die genauere Kontrolle. Eine Bestätigungsstrecke mit befristetem Link zeigt das anschaulich: Eine Frist von sechzig Minuten, die in der ersten Stunde um 02:30 Uhr Ortszeit gesetzt wird, endet in der zweiten Stunde wieder um 02:30 Uhr Ortszeit, also bei derselben Anzeige eine Stunde später. Was dabei auf der Strecke sonst noch schiefgehen kann, beschreibt der Beitrag Double-Opt-in-Strecke überwachen.

Checkliste für die Nacht

Die Vorbereitung ist eine Stunde Arbeit, verteilt auf Systeme, die selten dieselbe Person betreut. Sieben Punkte decken erfahrungsgemäß den größten Teil ab; sie lassen sich in derselben Reihenfolge abarbeiten, in der die Fehler auftreten würden.

• Zeitzone der Auswertung prüfen: In welcher Zeitzone werden Berichte, Diagramme und Ausleitungen gerechnet, und steht diese Zeitzone in der Ausgabe?
• Zeitgesteuerte Aufträge sichten: Welche laufen zwischen 01:30 und 03:30 Uhr Ortszeit, und was geschieht, wenn einer davon ausfällt oder ein zweites Mal läuft?
• Erwartungsfenster weiten: Betroffene Herzschlag-Prüfungen bekommen für diese eine Nacht eine Stunde mehr Spielraum.
• Wartungsfenster nachrechnen: Ein Fenster in Ortszeit hat an diesem Tag eine andere reale Dauer als geplant.
• Bereitschaftsplan prüfen: Wer hat die neunte Stunde, und liegt die Übergabe außerhalb der doppelten Stunde?
• Zeitzonendaten aktualisieren: Paketstand prüfen, betroffene Dienste neu starten, mit einem Aufruf gegenproben.
• Vergleichszeiträume festlegen: Wochen- und Monatsberichte rechnen mit Kalendergrenzen in der Zeitzone statt mit festen Abständen.

Nach der Nacht: was ausgewertet wird

Am Montag nach der Umstellung lohnen sich drei Blicke. Erstens die Liste der zeitgesteuerten Läufe dieser Nacht: Fehlt einer, ist die Ursache in der Regel die doppelte Stunde und nicht der Dienst selbst. Zweitens die Ereigniszahlen je Stunde: Ein Ausschlag um 02:00 Uhr, der ungefähr doppelt so hoch ist wie die Nachbarstunden, ist kein Angriff, sondern eine Gruppierung in Ortszeit. Drittens die Wochenzahlen: Wer die 169 Stunden nicht berücksichtigt, meldet ein Wachstum, das aus der Umstellung stammt und im Frühjahr als Rückgang zurückkommt.

Der Aufwand für all das ist gering, verteilt sich aber über Systeme, die selten dieselbe Person betreut. Deshalb hilft eine Stelle, an der die Zeitzone einmal eingestellt wird und danach für Prüfungen, Alarme und Berichte gleichermaßen gilt. Wer sehen möchte, wie das mit echten Messreihen aussieht, findet unter Demo einen Zugang mit Beispieldaten; die Auswertung weist dort die zugrunde gelegte Zeitzone in jeder Ansicht aus. Damit wird aus der Nacht zum 25. Oktober 2026 das, was sie sein sollte: eine Stunde mehr Schlaf für die Bereitschaft und ein Datenpunkt mehr in der Auswertung.