Cron-Zeitzone umrechnen: Uhrzeit statt Ausdruck

Was macht dieses Tool?

Es dreht die Eingaberichtung um, die bei Cron-Werkzeugen üblich ist. Der Bauplan der Konkurrenz sieht so aus: du tippst 0 9 * * 1-5 ein, das Werkzeug sagt dir „jeden Werktag um 09:00” und listet die nächsten Ausführungen auf. Das ist nützlich, wenn du den Ausdruck vor dir liegen hast, etwa weil er in einer fremden Konfigurationsdatei steht. Beim Schreiben eines neuen Jobs hast du ihn aber nicht. Du hast eine Uhrzeit im Kopf.

Also ist die Uhrzeit hier die Eingabe. Du trägst 09:00 ein, wählst Berlin, klickst auf „werktags”, und bekommst vier fertige Blöcke: die Zeile für crontab -e, den schedule-Block einer GitHub-Actions-Datei, ein vollständiges Kubernetes-CronJob-Manifest und den Befehl für AWS EventBridge Scheduler. Jeder Block trägt den Schlüssel, mit dem sein Ziel die Zeitzone speichert, und darunter steht dieselbe Zeitangabe als feste UTC-Zeile, für Umgebungen, die diesen Schlüssel nicht kennen.

Alles rechnet im Browser. Keine Eingabe wird verschickt, es gibt kein Konto und keine Anmeldung.

Warum ist die Zeitzone bei Cron so ein Problem?

Weil Cron selbst keine kennt. Die fünf Felder eines Ausdrucks enthalten Minute, Stunde, Tag des Monats, Monat und Wochentag, aber nirgends eine Zone. Welche Uhr gemeint ist, entscheidet die Umgebung, in der die Zeile ausgewertet wird. Auf einem Server ist das dessen Systemzeit, in einem Container meistens UTC, in einer verwalteten Plattform das, was der Anbieter festgelegt hat.

Daraus entsteht ein Fehler, den niemand beim Schreiben bemerkt. Die Zeile ist syntaktisch richtig, sie wird angenommen, der Job läuft, es gibt keine Fehlermeldung. Er läuft nur zur falschen Stunde. Und weil er zuverlässig zur falschen Stunde läuft, fällt es oft erst auf, wenn jemand fragt, warum der Bericht schon um sieben im Postfach liegt.

Der zweite Teil des Problems ist die Sommerzeit. Selbst wenn du korrekt umrechnest, gilt deine Rechnung nur bis zur nächsten Umstellung. 09:00 Berliner Zeit sind im Sommer 07:00 UTC und im Winter 08:00 UTC. Wer im August eine UTC-Zeile schreibt, hat sie ab dem 25. Oktober 2026 eine Stunde falsch, ohne dass irgendetwas kaputtgeht. In der EU steht die Abschaffung der Zeitumstellung seit Jahren still, weil sich die Mitgliedstaaten nicht auf eine dauerhafte Zeit einigen können. Damit bleibt das Thema auf absehbare Zeit erhalten.

Welche Schlüssel gibt es für die Zeitzone?

Alle vier Ziele können die Zone inzwischen selbst tragen. Sie heißen nur überall anders, und genau das ist der Grund, warum Leute die Umrechnung von Hand machen, obwohl sie es nicht müssten.

Ziel	Schlüssel	Verfügbar seit
crontab (cronie, Vixie)	CRON_TZ=Europe/Berlin	Vixie-Cron 4.0
GitHub Actions	timezone: "Europe/Berlin"	März 2026
Kubernetes CronJob	spec.timeZone	Kubernetes 1.27
AWS EventBridge Scheduler	--schedule-expression-timezone	November 2022
Systemd-Timer	OnCalendar=... Europe/Berlin	systemd 242

Die Tabelle hat einen Nachzügler und eine Lücke. Der Nachzügler ist GitHub Actions: bis März 2026 kannte der schedule-Block ausschließlich UTC, dann kam der timezone-Schlüssel dazu. Die GitHub-Dokumentation zeigt ihn heute als reguläres Beispiel. Weil die Änderung neu ist, steht in vielen Anleitungen, in alten Forenantworten und auf mehreren Konkurrenz-Seiten weiterhin, Actions könne nur UTC. Das stimmt nicht mehr.

Die Lücke sind klassische EventBridge-Regeln. Anders als der Scheduler haben sie keinen Zeitzonen-Parameter, und AWS führt sie in der eigenen Dokumentation inzwischen als Altbestand mit einem Hinweis auf den Scheduler. Wer sie weiter benutzt, kommt um die feste UTC-Zeile nicht herum, und für die gilt der Kasten zur Zeitumstellung.

Warum verschiebt sich der Wochentag?

Das ist der Fehler, der am längsten unentdeckt bleibt, weil er nur bei bestimmten Zonen auftritt und dann jede Woche.

Nimm 06:00 an einem Montag in Tokio. Tokio liegt neun Stunden vor UTC, also sind das 21:00 UTC. Aber am Sonntag, nicht am Montag. Wer die Stunde umrechnet und im Wochentag-Feld die 1 für Montag stehen lässt, schreibt 0 21 * * 1 und startet den Job jeden Montagabend, also 24 Stunden nach dem gewünschten Zeitpunkt. Richtig ist 0 21 * * 0.

Dieselbe Falle in die andere Richtung: 20:00 an einem Freitag in New York sind 00:00 UTC am Samstag. Und die Zonen mit halben Stunden verschärfen es noch, weil dort auch das Minutenfeld nicht bleiben darf, wo es war. 09:00 in Kolkata sind 03:30 UTC, nicht 03:00, denn Indien liegt fünfeinhalb Stunden vor UTC. Nepal liegt bei UTC+5:45, die Chatham-Inseln bei UTC+12:45.

Das Tool verschiebt Wochentag und Minutenfeld mit. Bei einem monatlichen Muster verschiebt es auch den Tag des Monats, solange das geht, und sagt es dir, wenn es nicht geht. Der erste eines Monats lässt sich nämlich nicht um einen Tag zurückschieben: „der letzte Tag des Vormonats” ist keine feste Zahl, die ins Tagesfeld passt.

Wann verrutscht meine feste UTC-Zeile?

Genau dann, wenn die gewählte Zone ihre Uhr umstellt. Das Tool sucht dieses Datum in der Zeitzonen-Datenbank, die dein Browser ohnehin mitbringt, und nennt es beim Namen, zusammen mit der Richtung, dem Betrag und der Uhrzeit, zu der die Zeile danach tatsächlich losläuft.

Die nächsten Termine liegen dichter beieinander, als man denkt, und nicht alle Zonen ziehen gleichzeitig. Sydney stellt am 4. Oktober 2026 vor, weil auf der Südhalbkugel die Sommerzeit dann erst beginnt. Berlin stellt am 25. Oktober 2026 zurück. New York folgt eine Woche später, am

1. November 2026, weil die USA einer eigenen Regel folgen. Wer Jobs in mehreren Regionen plant, hat also drei verschiedene Stichtage innerhalb von fünf Wochen.

Manche Zonen stellen gar nicht um. Kolkata bleibt das ganze Jahr bei UTC+5:30, Tokio bei UTC+9, São Paulo hat die Sommerzeit vor Jahren abgeschafft. Für diese Zonen sagt das Tool das ausdrücklich, statt eine Warnung anzuzeigen, die nicht zutrifft. Eine feste UTC-Zeile ist dort dauerhaft richtig.

Was tue ich gegen die Verschiebung?

Vier Wege, in der Reihenfolge, in der sie sich lohnen.

Der erste ist der Schlüssel aus der Tabelle oben. Wenn dein Ziel ihn unterstützt, gibt es das Problem nicht, denn dann rechnet das System die Sommerzeit selbst mit. Das ist der Grund, warum die vier Blöcke im Tool die Zeitzone eingebaut haben und nicht die umgerechnete Zeile zeigen.

Der zweite ist ein Wechsel des Ziels. Klassische EventBridge-Regeln lassen sich durch einen Scheduler-Eintrag ersetzen, ein busybox-Container durch ein Basis-Image mit cronie. Beides ist einmal Aufwand statt zweimal im Jahr.

Der dritte ist Handarbeit mit Erinnerung. Wenn die Zeile fest bleiben muss, trag dir das Datum aus dem Kasten in den Kalender und zieh die Stunde dort nach. Das funktioniert, solange sich jemand zuständig fühlt.

Der vierte ist, die Verschiebung bewusst hinzunehmen. Ein nächtlicher Aufräum-Job, der im Winter um zwei statt um drei läuft, stört niemanden. Diese Entscheidung ist völlig in Ordnung, sie sollte nur eine Entscheidung sein und keine Überraschung im November.

Was ist mit der Pünktlichkeit selbst?

Ein Punkt, der mit Zeitzonen nichts zu tun hat, aber dieselben Beschwerden auslöst: geplante GitHub-Actions-Läufe starten regelmäßig verspätet. GitHub sagt die Minute nicht zu, und zu vollen Stunden, wenn viele Zeitpläne gleichzeitig fällig sind, staut sich die Warteschlange.

Das ist wichtig zu wissen, bevor du dem Tool die Schuld gibst. Wenn dein Job vier Stunden zu spät läuft, liegt das nicht an der Umrechnung, denn eine Zeitzone verschiebt um eine ganze oder eine halbe Stunde und nie um vier. Wenn dein Job dagegen konstant exakt eine Stunde daneben liegt, ist es fast immer die Zone oder die Sommerzeit. Der Betrag der Abweichung sagt dir also schon, wo du suchen musst.

Braucht mein Ausdruck wirklich eine Zeitzone?

Nicht immer. Wenn dein Job zu einer festen Uhrzeit laufen soll, die jemand sieht, also ein Bericht zum Arbeitsbeginn, eine Abrechnung zum Geschäftsschluss, eine Erinnerung am Morgen, dann ja. Diese Zeiten sind an eine Ortszeit gebunden, und eine Stunde daneben ist sichtbar.

Wenn dein Job nur regelmäßig laufen soll, also alle 15 Minuten aufräumen, stündlich einen Cache erneuern, nachts irgendwann sichern, dann nicht. Für solche Jobs ist UTC die einfachere Wahl, weil sie nie umgestellt wird und du dir die ganze Frage sparst. Der Cron-Expression-Builder ist dafür das passendere Werkzeug, dort tippst du den Ausdruck direkt und bekommst ihn erklärt.

Die Faustregel: bindet die Uhrzeit an einen Menschen, brauchst du eine Zone. Bindet sie nur an ein Intervall, brauchst du keine.