Cron timezone converter: a time in, a line out

What does this tool do?

It reverses the input direction cron tools normally use. The usual blueprint goes like this: you type 0 9 * * 1-5, the tool tells you “every weekday at 09:00” and lists the next few runs. That is useful when the expression is already in front of you, because it sits in somebody else’s config file. When you are writing a new job, you do not have it. You have a time in your head.

So here the time is the input. You enter 09:00, pick Berlin, click “weekdays”, and get four finished blocks: the line for crontab -e, the schedule block of a GitHub Actions file, a complete Kubernetes CronJob manifest and the command for AWS EventBridge Scheduler. Each block carries the key its target uses to store the timezone, and below it the same moment as a fixed UTC line, for environments that do not know that key.

Everything computes in the browser. Nothing you type is sent anywhere, and there is no account.

Why is the timezone such a problem in cron?

Because cron itself has none. The five fields of an expression hold minute, hour, day of month, month and day of week, and nowhere a zone. Which clock is meant is decided by whatever evaluates the line. On a server that is its system time, in a container it is usually UTC, on a managed platform it is whatever the provider decided.

The result is a bug nobody notices while writing it. The line is syntactically correct, it is accepted, the job runs, no error appears. It just runs at the wrong hour. And because it runs at the wrong hour reliably, it often surfaces only when somebody asks why the report is already in their inbox at seven.

The second half of the problem is daylight saving. Even a correct conversion is only correct until the next transition. 09:00 Berlin time is 07:00 UTC in summer and 08:00 UTC in winter. Write a UTC line in August and it is an hour wrong from 25 October 2026 onward, with nothing breaking to tell you. In the EU, abolishing the clock change has been stalled for years because member states cannot agree on which permanent time to keep, so this is not going away soon.

Which timezone keys exist?

All four targets can carry the zone themselves now. They just call it something different each time, which is exactly why people still convert by hand when they no longer need to.

Target	Key	Available since
crontab (cronie, Vixie)	CRON_TZ=Europe/Berlin	Vixie cron 4.0
GitHub Actions	timezone: "Europe/Berlin"	March 2026
Kubernetes CronJob	spec.timeZone	Kubernetes 1.27
AWS EventBridge Scheduler	--schedule-expression-timezone	November 2022
Systemd timers	OnCalendar=... Europe/Berlin	systemd 242

The table has one latecomer and one gap. The latecomer is GitHub Actions: until March 2026 the schedule block understood UTC and nothing else, then the timezone key arrived. The GitHub documentation now shows it as an ordinary example. Because the change is recent, a lot of tutorials, old forum answers and several competing tools still say Actions is UTC-only. That is no longer true.

The gap is classic EventBridge rules. Unlike Scheduler they have no timezone parameter, and AWS now lists them in its own docs as a legacy feature with a pointer to Scheduler. If you keep using them, the fixed UTC line is unavoidable, and the clock-change panel applies to you.

Why does the weekday shift?

This is the mistake that survives longest undetected, because it only happens with certain zones, and then it happens every week.

Take 06:00 on a Monday in Tokyo. Tokyo runs nine hours ahead of UTC, so that is 21:00 UTC. On Sunday though, not Monday. Convert the hour and leave the 1 for Monday in the weekday field and you get 0 21 * * 1, which starts the job every Monday evening, a full 24 hours after the moment you wanted. The correct line is 0 21 * * 0.

The same trap runs the other way: 20:00 on a Friday in New York is 00:00 UTC on Saturday. Half-hour zones sharpen it further, because there the minute field cannot stay where it was either. 09:00 in Kolkata is 03:30 UTC, not 03:00, because India runs five and a half hours ahead. Nepal sits at UTC+5:45, the Chatham Islands at UTC+12:45.

The tool moves the weekday and the minute field along. For a monthly pattern it moves the day of month too, as long as that is possible, and tells you when it is not. The first of a month cannot be rolled back by a day: “the last day of the previous month” is not a fixed number that fits in the day field.

When exactly does my fixed UTC line slip?

Precisely when the zone you picked changes its clock. The tool looks that date up in the timezone database your browser already carries, and names it, together with the direction, the amount and the clock time the line will actually fire at afterwards.

The upcoming dates sit closer together than people expect, and not every zone moves at once. Sydney springs forward on 4 October 2026, because in the southern hemisphere summer time is only starting then. Berlin falls back on 25 October 2026. New York follows a week later, on 1 November 2026, because the United States follows its own rule. Schedule jobs across regions and you have three different deadlines inside five weeks.

Some zones never move at all. Kolkata stays at UTC+5:30 all year, Tokyo at UTC+9, and São Paulo dropped daylight saving years ago. For those the tool says so explicitly rather than showing a warning that does not apply. A fixed UTC line is permanently correct there.

What do I do about the drift?

Four routes, in the order they pay off.

The first is the key from the table above. If your target supports it, the problem does not exist, because the system handles daylight saving itself. That is why the four blocks in the tool have the timezone built in rather than showing you a converted line.

The second is changing target. A classic EventBridge rule can be replaced by a Scheduler entry, a busybox container by a base image with cronie. Both are one-off work instead of twice-a-year work.

The third is manual work with a reminder. If the line has to stay fixed, put the date from the panel in your calendar and adjust the hour there. That works as long as somebody feels responsible for it.

The fourth is accepting the shift on purpose. A nightly cleanup job that runs at two instead of three in winter bothers nobody. That is a perfectly good decision, it just needs to be a decision rather than a surprise in November.

What about punctuality itself?

One point that has nothing to do with timezones but produces the same complaints: scheduled GitHub Actions runs regularly start late. GitHub does not promise the minute, and on the hour, when a lot of schedules come due at once, the queue backs up.

This is worth knowing before you blame the conversion. If your job runs four hours late, that is not the timezone, because a zone shifts things by a whole or a half hour and never by four. If your job is consistently exactly one hour off, it is almost always the zone or daylight saving. The size of the error already tells you where to look.

Does my expression really need a timezone?

Not always. If your job has to run at a fixed hour somebody sees, so a report at the start of the working day, a settlement at close of business, a reminder in the morning, then yes. Those times are tied to a local clock, and an hour off is visible.

If your job only has to run regularly, so clean up every 15 minutes, refresh a cache hourly, back something up at some point overnight, then no. For those, UTC is the simpler choice, because it never changes and you skip the whole question. The cron expression builder is the better tool for that case, where you type the expression directly and have it explained.

The rule of thumb: if the time is tied to a person, you need a zone. If it is tied only to an interval, you do not.