Cron-Ausdruck im Klartext übersetzen

Ein Standard-Cron-Ausdruck hat fünf Felder, getrennt durch Leerzeichen: Minute (0–59), Stunde (0–23), Tag des Monats (1–31), Monat (1–12) und Wochentag (0–7, wobei 0 und 7 beide Sonntag meinen). Von links nach rechts wird der Zeitpunkt also immer gröber.

Die wichtigsten Zeichen: * steht für „jeder Wert”, */5 für „alle fünf”, 1-5 für einen Bereich und 1,15 für eine Liste. Beispiele: 0 3 * * * läuft täglich um 3:00 Uhr, */15 * * * * alle 15 Minuten und 0 9 * * 1 jeden Montag um 9:00 Uhr. Mehr dazu im Glossareintrag Cron. In der Praxis steht ein solcher Ausdruck meist als Zeile in einer Crontab, zusammen mit dem Befehl, der zu diesem Zeitpunkt laufen soll. Ob diese Uhrzeit in Serverzeit, UTC oder einer konfigurierten Zeitzone gemeint ist, prüfst du im Praxisleitfaden Zeitstempel und Zeitzonen in der Praxis. Hast du bereits einen konkreten Ausdruck vor dir, übersetzt ihn das Cron-Ausdruck-Werkzeug direkt Feld für Feld in Klartext.

Das hängt vom System ab, nicht vom Cron-Ausdruck selbst: Ein Ausdruck wie 0 3 * * * legt nur Minute und Stunde fest, aber keine Zeitzone. Ob diese Stunde als Serverzeit, UTC oder eine konfigurierte Zeitzone - etwa Europe/Berlin - ausgewertet wird, entscheidet die Umgebung, in der Cron läuft: das Betriebssystem, der Container oder der jeweilige Scheduler.

Wie du die Zeitzone deines Systems findest

Auf den meisten Linux-Systemen zeigt timedatectl oder date +%Z die aktuell aktive Zeitzone an. Läuft der Job in einem Container oder bei einem verwalteten Scheduler, steckt die Zeitzone häufig in der Umgebungsvariable TZ oder in der Konfiguration des jeweiligen Dienstes - ein Blick in Umgebungsvariablen und Dokumentation des Systems schafft Klarheit, wenn date allein keine eindeutige Antwort liefert. Wichtig: Diese Einstellung gilt für das System als Ganzes, nicht für den einzelnen Cron-Ausdruck.

Warum das bei 0 3 * * * wichtig ist

Steht die Systemzeitzone auf UTC, fallen 3 Uhr Serverzeit und 3 Uhr UTC zusammen - derselbe Moment. Steht sie auf Europe/Berlin, liegt 3 Uhr Serverzeit ein bis zwei Stunden vor 3 Uhr UTC, je nachdem ob gerade Sommer- oder Winterzeit gilt (die IANA-Zeitzonendatenbank, die die meisten Systeme über Intl oder vergleichbare Bibliotheken nutzen, pflegt genau diese Umstellungsregeln). Wer den Ausdruck als „3 Uhr UTC” liest, obwohl das System Europe/Berlin verwendet, plant den Job effektiv für einen anderen Moment als beabsichtigt. Bei mehreren Servern in unterschiedlichen Zeitzonen - oder wenn ein Hostingdienst die Zeitzone beim Deployment stillschweigend ändert - wird dieser Unterschied besonders leicht übersehen.

Weiterrechnen

Einen konkreten Ausdruck übersetzt der Cron-Ausdruck-Rechner Feld für Feld. Wie Zeitpunkt, UTC und lokale Anzeige allgemein zusammenhängen, erklärt der Praxisleitfaden Zeitstempel und Zeitzonen in der Praxis. Was zusätzlich an Umstellungstagen zwischen Sommer- und Winterzeit passiert, steht in der FAQ Was passiert mit Cronjobs bei der Zeitumstellung?.

An den beiden Tagen der Zeitumstellung kann die für einen Cronjob geplante Stunde fehlen oder doppelt vorkommen, je nachdem, ob der Job auf eine lokale Uhrzeit oder auf einen festen Abstand geplant ist. Bei einem lokal-zeitbasiert geplanten Job wie 30 2 * * * überspringt die Uhr im Frühjahr die geplante Zeit oder durchläuft sie im Herbst zweimal. Ein Job, der stattdessen mit festem UTC-Abstand oder einfach alle 24 Stunden läuft, kennt dieses Problem nicht, verschiebt sich dafür lokal betrachtet zeitweise um eine Stunde.

Frühjahr - wenn die geplante Stunde fehlt

Beim Sprung von der Winter- in die Sommerzeit überspringt die lokale Uhr eine Stunde, meist mitten in der Nacht: Aus 2:00 Uhr wird direkt 3:00 Uhr. Ein Job, der für 2:30 Uhr geplant ist, trifft an diesem Tag lokal auf keinen gültigen Zeitpunkt - diese halbe Stunde existiert an diesem Tag schlicht nicht. Was dann passiert, hängt vom eingesetzten Scheduler ab: Manche Implementierungen lassen den Lauf für diesen Tag ausfallen, andere holen ihn direkt nach dem Sprung nach oder verschieben ihn auf die nächste gültige Zeit. Ein allgemeingültiges „richtiges” Verhalten gibt es dafür nicht - das regelt die jeweilige Cron-Implementierung oder der Scheduler-Dienst.

Herbst - wenn die geplante Stunde doppelt vorkommt

Beim Rücksprung von der Sommer- in die Winterzeit läuft die Stunde zwischen 2:00 und 3:00 Uhr lokal zweimal ab. Ein Job für 2:30 Uhr trifft an diesem Tag also auf zwei Momente, die beide als lokale 2:30 Uhr erscheinen. Auch hier entscheidet der Scheduler, was passiert: Er kann den Job bei beiden Durchläufen starten, nur beim ersten oder nur beim zweiten. Wem wichtig ist, ob ein bestimmter Job an diesem Tag ein- oder zweimal läuft, sollte das Verhalten der eigenen Umgebung gezielt prüfen statt es anzunehmen.

Warum lokal geplante Jobs anders betroffen sind als UTC-Jobs

Der Unterschied liegt darin, wonach der Job seine Ausführungszeit bestimmt. Ein Cron-Ausdruck wie 30 2 * * * beschreibt nur eine Uhrzeit, keine Zeitzone - ob diese Uhrzeit lokal oder in UTC gilt, entscheidet die Laufzeitumgebung (Details dazu in der FAQ Läuft mein Cronjob in UTC oder Lokalzeit?). Läuft die Umgebung in einer Zeitzone mit Sommerzeit, trifft die geplante Stunde genau an den beiden Umstellungstagen auf das Fehl- beziehungsweise Doppel-Problem. Ein Job mit festem UTC-Abstand hat dieses Problem nicht, weil UTC keine Zeitumstellung kennt - er läuft dafür für ein halbes Jahr lokal betrachtet eine Stunde früher oder später als in der übrigen Zeit, weil sich die lokale Zeitzone relativ zu UTC verschiebt.

Weiterrechnen

Ob ein eigener Ausdruck lokal-zeitbasiert oder mit festem UTC-Abstand ausgewertet wird, klärt die FAQ Läuft mein Cronjob in UTC oder Lokalzeit?. Einen konkreten Ausdruck übersetzt der Cron-Ausdruck-Rechner Feld für Feld in Klartext. Wie Zeitpunkt, UTC und lokale Anzeige allgemein zusammenhängen, erklärt der Praxisleitfaden Zeitstempel und Zeitzonen in der Praxis.