Cron-Expression-Dialekte: Felder, Sekunden und die Falle bei Tag des Monats und Wochentag

Worum es geht

«Cron Expression» bezeichnet mindestens fünf zueinander inkompatible Grammatiken:

Dialekt	Feldreihenfolge	Sekunden	Jahr	Tag des Monats + Wochentag
Vixie cron / cronie crontab(5)	minute hour dom month dow (5 Felder)	nein	nein	ODER, wenn beide eingeschränkt sind (keines ist *)
Quartz CronTrigger	seconds minutes hours dom month dow [year] (6 oder 7 Felder)	ja, erstes Feld	optionales 7. Feld	genau eines von beiden muss ? sein; * in beiden wird abgelehnt
Kubernetes CronJob	minute hour dom month dow (5 Felder); die Zeitzone steht in .spec.timeZone, nicht im String	nein	nein	ODER, wie bei Vixie cron
GitHub Actions schedule	minute hour dom month dow (5 Felder), POSIX-Syntax; UTC, sofern am Eintrag keine IANA-timezone: gesetzt ist	nein	nein	in der GitHub-Dokumentation nicht gesondert erwähnt; POSIX-cron definiert ODER
AWS EventBridge cron()-Regeln	minutes hours dom month dow year (6 Felder), Auswertung in UTC	nein	erforderlich, 6. Feld	ein Wert oder * in einem der Felder erfordert ? im anderen

Die Man-Page von crontab(5) hält fest, dass bei Einschränkung beider Tagesfelder gilt: "the command will be run when either field matches the current time" – das entspricht einem ODER. Quartz und EventBridge untersagen dagegen die Angabe beider Felder und verlangen in einem von beiden den Platzhalter ?.

Warum es wichtig ist

Schon kleine Anpassungen an einem Zeitplan-String, der für ein bestimmtes System geschrieben wurde, verändern dessen Bedeutung in einem anderen System unbemerkt oder führen zur Ablehnung. Ein Quartz-String, der in ein Kubernetes-Manifest kopiert wird, besteht die Validierung nicht (zu viele Felder, keine Sekundenunterstützung). Ein EventBridge-Cron-String ohne Jahresfeld ist ungültig. Die CronJob-Dokumentation von Kubernetes weist die Zeitzonenbehandlung ausdrücklich dem separaten Feld .spec.timeZone zu (seit v1.27 stabil). Sie hält ausserdem fest, dass ein CRON_TZ-/TZ-Präfix im Schedule-String "is not officially supported (and never has been)" und dass aktuelle Versionen einen solchen Zeitplan mit einem Validierungsfehler ablehnen.

So wird es angewendet

• Den fertigen String vor dem Deployment mit dem Parser des Zielsystems prüfen, nicht mit einem generischen Cron-Validator.
• Bei Kubernetes .spec.timeZone setzen, statt ein Zeitzonenpräfix in .spec.schedule einzubetten.
• GitHub-Actions-Zeitpläne laufen in UTC, solange der Eintrag kein timezone: setzt (ein IANA-Name wie Europe/Zurich). Sie lösen nie häufiger als alle 5 Minuten aus und können unter Last verzögert werden oder ausfallen, besonders zu Beginn einer vollen Stunde.
• Bei EventBridge immer genau 6 Felder inklusive Jahr angeben, in dem Feld von Tag des Monats und Wochentag, das nicht eingeschränkt werden soll, ? setzen und die Zeiten in UTC angeben (geplante Regeln haben keine Zeitzoneneinstellung).
• Bei Quartz beachten, dass der String 6 oder 7 Felder haben kann: Das Jahr wegzulassen ist gültig, die Sekunden wegzulassen nicht.

Stolpersteine

• Annehmen, Kubernetes und EventBridge hätten dieselbe Regel für Tag des Monats und Wochentag: Kubernetes verknüpft beide wie klassisches cron per ODER, EventBridge verlangt, dass genau eines von beiden ? ist.
• Vergessen, dass ein 7-Felder-String mit Jahr aus Quartz überall sonst ungültig ist.
• timezone: zu einem GitHub-Actions-Zeitplan hinzufügen, dessen Zeiten bereits von Hand in UTC umgerechnet wurden.