Zeitumstellung 25.10.: Cronjobs und Zeitstempel im Shop

Ein klassischer Zeitplaner vergleicht seine Felder mit der aktuellen Ortszeit des Systems. Genau daraus folgt das Verhalten, das die Handbuchseite der cronie-Linie ungewöhnlich deutlich benennt: Nicht existierende Zeiten wie die fehlenden Stunden während der Umstellung treffen auf keine Übereinstimmung, sodass dort geplante Jobs nicht ausgeführt werden; Zeiten, die mehr als einmal auftreten, lassen passende Jobs dagegen zweimal laufen (crontab(5)). Das ist kein Fehler der Umsetzung, sondern die dokumentierte Folge davon, dass ein Ortszeitfeld in diesen 60 Minuten kein eindeutiger Schlüssel ist. Ein Job, der auf 02:30 Ortszeit steht, wird am 25. Oktober 2026 auf einem solchen System in der Stunde 2A und noch einmal in der Stunde 2B ausgelöst – aus Sicht des Planers völlig regelkonform. Verallgemeinern lässt sich das trotzdem nicht: Die cron-Umsetzung der Debian-Linie regelt beide Fälle umgekehrt. Wird die Uhr um weniger als drei Stunden vorgestellt, werden dort Läufe, die in die übersprungene Zeit gefallen wären, kurz nach der Umstellung ausgeführt; wird sie um weniger als drei Stunden zurückgestellt, werden Läufe, die in die wiederholte Zeit fallen, nicht erneut ausgeführt. Betroffen sind dabei ausschließlich Einträge mit fester Uhrzeit, nicht solche mit einem Platzhalter in Stunde oder Minute (cron(8), Debian-Umsetzung). Welche der beiden Auslegungen auf dem eigenen Server arbeitet, beantwortet deren Handbuchseite – und davon hängt ab, ob in dieser Nacht der doppelte, der nachgeholte oder der stille Lauf das eigentliche Risiko ist.

Der zweite Lauf ist selten harmlos. Ein Bestandsabgleich, der Differenzen fortschreibt, zieht dieselbe Differenz ein zweites Mal ab. Ein Mahnlauf verschickt dieselbe Mahnung zweimal. Ein Rechnungslauf vergibt zwei Nummernkreise für denselben Vorgang. Ein Zahlungsabgleich bucht Positionen doppelt oder scheitert an einer Eindeutigkeitsprüfung und meldet einen Fehler, der am Montag niemand zuordnen kann. Umgekehrt trifft der ausgefallene Lauf im Frühjahr diejenigen Aufgaben am härtesten, die nur einmal am Tag laufen: Ein Nachtbackup mit fester Uhrzeit zwischen 2 und 3 Uhr wird auf einem Planer der cronie-Linie am Umstellungssonntag im März übersprungen, und die Lücke fällt erfahrungsgemäß erst auf, wenn jemand ein Rücksichern versucht. Wie stille Ausfälle von Hintergrundprozessen überhaupt sichtbar werden, behandelt der Beitrag zu Hintergrundjobs und Cronjobs im Shop im Detail; hier geht es um die davon getrennte Frage der doppelten und übersprungenen Läufe. Die folgende Tabelle beschreibt einen Planer der cronie-Linie; auf der Debian-Umsetzung entfällt der doppelte Lauf, und der übersprungene wird kurz nach der Umstellung nachgeholt (cron(8), Debian-Umsetzung).

Die Tabelle zeigt ein Muster: Betroffen ist nicht die Technik, sondern die Fachlichkeit. Ob ein doppelter Lauf schadet, hängt daran, ob die Aufgabe wiederholbar ist. Ein Cacheaufbau verträgt eine Wiederholung, eine Buchung nicht. Deshalb ist die erste Frage vor dem Umstellungswochenende keine technische, sondern eine inhaltliche: Welche der nachts laufenden Aufgaben verändern Zustände, die sich nicht folgenlos zweimal verändern lassen? Diese Liste ist in den meisten Shops kürzer, als sie zunächst wirkt – typischerweise geht es um eine Handvoll Läufe rund um Bestand, Zahlung und Belegnummern.

Die verbreitetste Fehlannahme lautet, die Datenbank kümmere sich schon. Das stimmt zur Hälfte. Für eine TIMESTAMP-Spalte gilt: Eingefügte Werte werden aus der Zeitzone der Sitzung nach koordinierter Weltzeit umgerechnet, wenn sie gespeichert werden, und beim Lesen in die Zeitzone der Sitzung zurückgerechnet (MariaDB-Dokumentation). Intern liegt also ein eindeutiger Zeitpunkt. Zugleich gilt aber: Ein Zeitzonenbezeichner wird nicht mitgespeichert (MariaDB-Dokumentation). Die Eindeutigkeit hängt damit vollständig an der Zeitzone der schreibenden Sitzung – und die kann sich zwischen Webprozess, Konsolenlauf und Hintergrunddienst unterscheiden, ohne dass es jemandem auffällt. Eine DATETIME-Spalte wiederum speichert genau das, was hineingeschrieben wurde, ohne jeden Bezug; in der Doppelstunde ist ihr Inhalt damit nicht auflösbar.

Die Umstellung ist auch der Grund, warum eine Zeitzone ohne Datum keine Aussage trägt. In einer anderen verbreiteten Datenbank ist das explizit dokumentiert: Wird ein Zeitzonenname verwendet, der eine Sommerzeitregel enthält, ist die Angabe des Datums erforderlich, um zu bestimmen, ob Normal- oder Sommerzeit gilt (PostgreSQL-Dokumentation). Der Standard für Zeitangaben im Netz zieht daraus die Konsequenz und definiert einen Zeitstempel als eine eindeutige Darstellung eines Zeitpunkts (IETF, RFC 3339); numerische Versätze werden dort als Ortszeit minus UTC berechnet (IETF, RFC 3339), der Versuch, Zonen mit Buchstabenkürzeln zu benennen, hat dagegen in der Vergangenheit zu schlechter Interoperabilität geführt (IETF, RFC 3339). Übersetzt in die Praxis heißt das: gespeichert wird Weltzeit oder eine Angabe mit numerischem Versatz, angezeigt wird Ortszeit.

Der Aufruf mit einem benannten Gebiet statt eines festen Versatzes setzt voraus, dass die Zeitzonentabellen der Datenbank befüllt sind – andernfalls liefert die Umrechnung keinen Wert und der Bericht bleibt leer, ohne dass ein Fehler gemeldet wird. Das ist eine der typischen stillen Fehlerquellen an diesem Wochenende: Die Abfrage läuft durch, die Ausgabe ist leer, und die leere Ausgabe wird als Ergebnis gelesen. Wer die Datenhaltung ohnehin regelmäßig prüft, findet die passenden Handgriffe im Beitrag zur Datenbankwartung und Optimierung.

Der Umbau selbst ist überschaubar und lässt sich in einer normalen Wartungsrunde erledigen. Er besteht aus vier Schritten: Zeitpläne auf einen eindeutigen Bezug stellen, kritische Läufe aus dem Zeitfenster zwischen 1 und 4 Uhr Ortszeit herausnehmen, die Wiederholbarkeit der verbleibenden Läufe absichern und den Regelbestand der Zeitzonendatenbank aktualisieren. Der erste Schritt ist der wirksamste. Ein Zeitplaner, der in Weltzeit rechnet, kennt weder Doppelstunde noch Lücke, weil die Weltzeit beides nicht hat. Für einen klassischen Zeitplaner geschieht das über eine Zeitzonenangabe in der Tabelle selbst, für Systemzeitgeber über das Kalenderfeld. Ob eine Zeitzonenangabe in der Tabelle von der eingesetzten cron-Umsetzung überhaupt ausgewertet wird, steht ebenfalls in deren Handbuchseite; wird sie nicht ausgewertet, bleibt sie eine wirkungslose Variable und der Zeitplan läuft weiter in Ortszeit.

Beim Kalenderausdruck ist die Zeitzone ein eigenes Feld: Sie kann als die wörtliche Zeichenkette „UTC“, die lokale Zeitzone oder eine Zeitzone im Format der IANA-Zeitzonendatenbank angegeben werden (systemd.time(7)). Ohne diese Angabe gilt die Ortszeit des Systems, und damit gilt auch die Doppelstunde. Der zweite nützliche Schalter betrifft ausgefallene Läufe: Ist er gesetzt, wird der Dienst unmittelbar ausgelöst, wenn er während der Inaktivität des Zeitgebers mindestens einmal ausgelöst worden wäre (systemd.timer(5)). Das holt Läufe nach, die während einer Inaktivität des Zeitgebers ausgefallen sind, und verlangt gerade deshalb, dass der Lauf wiederholbar ist – sonst tauscht man einen ausgefallenen gegen einen doppelten Lauf. Ein Ersatz für eine eindeutige Zeitangabe ist der Schalter nicht: Er greift bei Inaktivität des Zeitgebers, nicht bei der Mehrdeutigkeit der Ortszeit. Dieser Schalter wirkt ausdrücklich nur bei Zeitgebern, die mit einem Kalenderausdruck konfiguriert sind (systemd.timer(5)).

Der vierte Schritt wird gern übersehen. Die Regeln, nach denen ein System Ortszeit berechnet, stammen aus einer laufend gepflegten Datenbank; ihre aktuelle Fassung ist 2026c, veröffentlicht am 8. Juli 2026 (IANA Time Zone Database). Die Pflege ist kein Selbstzweck: Allein diese Fassung verzeichnet den Übergang Albertas auf einen dauerhaften Versatz zum 18. Juni 2026 und den Marokkos zum 20. September 2026 (IANA Time Zone Database). Endnutzer erhalten Aktualisierungen dieser Daten in der Regel über ihre Software- und Betriebssystemanbieter (IANA Time Zone Database) – auf einem Server heißt das: über die Paketverwaltung, und damit über die Update-Routine des Wartungsvertrags. Ein Server, dessen Zeitzonenpaket seit zwei Jahren steht, rechnet an den Umstellungstagen mit alten Regeln. Welche Rolle diese Routine im Gesamtbild spielt, zeigt die Übersicht der Wartungsleistungen.

Die Ausgabe von zdump ist der schnellste Nachweis, dass ein System die Regeln kennt: Sie zeigt den Schnitt am 25. Oktober 2026 um 01:00 Weltzeit und den Sprung der Ortszeit von 02:59:59 auf 02:00:00. Fehlt diese Zeile oder nennt sie ein anderes Datum, ist der Regelbestand veraltet und alles Weitere hinfällig. Der dritte Befehl beantwortet die zweite Frage: Welchen Zeitpunkt meint ein Kalenderausdruck tatsächlich? Wer ihn für die kritischen Zeitpläne einmal ausführt, sieht sofort, welche Läufe in der Doppelstunde liegen. Beide Prüfungen gehören in dieselbe Runde wie die Terminplanung des Wartungsfensters ohne Umsatzausfall.

Am Sonntagmorgen sind drei Fragen zu beantworten, und zwar in dieser Reihenfolge. Erstens: Ist jeder geplante Lauf genau einmal gelaufen? Der Nachweis kommt aus dem Laufprotokoll je Kalendertag, nicht aus dem Gefühl, dass keine Alarme kamen – ein ausgefallener Lauf erzeugt typischerweise keine Meldung. Zweitens: Gibt es Vorgänge mit zwei Buchungen, zwei Belegen oder zwei Nachrichten in der Doppelstunde? Dafür genügt eine Abfrage über den Zeitraum von 22:00 Uhr Weltzeit am Vortag bis 02:00 Uhr Weltzeit, gruppiert nach Vorgang. Drittens: Zeigen die Kennzahlen des Tages Auffälligkeiten, die sich allein aus der zusätzlichen Stunde erklären? Wenn ja, gehört das in die Fußnote des Berichts, damit im nächsten Quartal niemand nach einer Ursache sucht, die es nicht gibt.

Am Montag folgt der langweilige, aber entscheidende Teil: Was in dieser Nacht auffiel, wird als dauerhafte Änderung festgeschrieben und nicht als Notiz für das nächste Mal. Zeitpläne, die noch in Ortszeit standen, werden umgestellt. Läufe, die sich als nicht wiederholbar erwiesen haben, bekommen eine Sperre je Vorgang. Der nächste Umstellungstermin – der letzte Sonntag im März 2027 – wandert in denselben Kalender wie Update- und Zertifikatsfristen. Genau dafür ist ein SLA-Wartungsvertrag da: Er hält solche wiederkehrenden Termine fest, damit sie nicht von der Erinnerung einzelner Personen abhängen. Eine verwandte Aufräumaufgabe mit demselben Muster – wiederkehrend, unauffällig, im Ernstfall teuer – ist das Entziehen von Zugängen beim Offboarding.