FACHWISSEN · PROJEKTE & TRANSFORMATIONINSIGHTS · PROJECTS & TRANSFORMATION
Automatisierung zur Sommerzeit: Warum täglich um 02:30 Uhr eine Sonderregel brauchtDaylight-saving automation: why a daily 02:30 schedule needs an exception rule
Ein Ablauf soll jeden Tag um 02:30 Uhr Ortszeit starten. Bei einer Zeitumstellung kann diese Uhrzeit jedoch fehlen oder zweimal vorkommen. Welche Ausführung dann stattfindet, hängt vom verwendeten Zeitplaner und seiner Konfiguration ab. Eine normale Woche allein reicht deshalb nicht als Test für einen kalenderbasierten Prozess.
Ortszeit ist keine feste Zeitdauer
Eine lokale Kalenderregel orientiert sich an einer Zeitzone. Ein Abstand von 24 Stunden beschreibt dagegen verstrichene Zeit. An Tagen mit Zeitumstellung können diese Regeln zu unterschiedlichen örtlichen Startzeiten führen. Für den Prozess muss feststehen, welche Bedeutung fachlich benötigt wird.
Ein fiktiver Abrechnungslauf
Ein täglicher Lauf verarbeitet die offenen Vorgänge eines lokalen Geschäftstags. Das Team entscheidet ausdrücklich, wie ein fehlender Startzeitpunkt behandelt wird: überspringen, nachholen oder auf eine andere Uhrzeit verschieben. Für einen doppelt vorkommenden Zeitpunkt wird ebenfalls festgelegt, ob ein oder zwei Läufe zulässig sind. Das Systemverhalten wird anschließend gegen diese Regel geprüft.
Den Zeitplaner nicht erraten
Verschiedene Werkzeuge können unterschiedliche Vorgaben haben. Beispielsweise kann eine nicht vorhandene Uhrzeit ausgelassen werden, während eine doppelte Uhrzeit nur einmal ausgeführt wird. Daraus darf keine allgemeine Regel für jedes System abgeleitet werden. Dokumentiert werden verwendete Zeitzone, konkrete Konfiguration und beobachtetes Verhalten.
Auch Wiederanläufe fachlich absichern
Ein nachgeholter Lauf sollte erkennen, welchen Zeitraum er tatsächlich verarbeiten soll. Eine eindeutige Periodenkennung kann dabei hilfreicher sein als die bloße aktuelle Uhrzeit. Zusätzlich werden Neustarts und verspätete Ausführungen getestet. So entsteht ein überprüfbarer Ablauf, der einen Geschäftstag kontrolliert bearbeitet, statt zufällig von der Uhrdarstellung einer einzelnen Maschine abhängig zu sein.
A workflow is scheduled to run every day at 02:30 local time. During a daylight-saving transition, that time may not exist or may occur twice. The resulting execution depends on the scheduler and its configuration. Testing only an ordinary week is therefore insufficient for a calendar-based process.
Local time is not a fixed duration
A local calendar rule follows a time zone. A 24-hour interval instead measures elapsed time. On a clock-change day, these rules can produce different local start times. The process needs an explicit decision about which meaning is required by the business operation.
A fictional daily processing run
A daily job processes outstanding transactions for a local business day. The team explicitly decides how to handle a missing start time: skip it, catch up or move it to another time. It also defines whether a repeated local time permits one execution or two. The actual system behaviour is then tested against that rule.
Do not guess the scheduler behaviour
Different tools can apply different policies. One may skip a non-existent time while invoking a repeated time only once. That does not establish a universal rule for every system. Record the selected time zone, exact configuration and observed behaviour rather than relying on an assumption about the platform.
Protect recovery paths too
A catch-up run should identify which period it must process. An unambiguous period identifier can be more useful than simply reading the current clock. Test restarts and delayed execution as well. This produces a verifiable workflow that handles a business day deliberately instead of depending accidentally on the clock display of a particular machine.