Developer & system utilities
Cron timezone predictor
Stop guessing when a job runs. Enter a cron expression, choose the server's zone, and see the next fire times — spelled out in that zone and in your own local time.
Standard 5-field cron: minute, hour, day-of-month, month, day-of-week. Supports *, */5, 1-5, and lists like 0,30.
How to use the cron timezone predictor
Enter the cron expression
Paste the schedule as you would write it in a crontab — five fields for minute, hour, day of month, month and day of week.
Choose the zone it runs in
Set the zone the scheduler itself uses. This is the value that decides everything, and it is frequently not the one people assume.
Read the next fire times
You get the upcoming runs as real instants, shown in both the scheduler's zone and yours, so you can see when the job will actually go off.
Look for the daylight-saving anomalies
Check the runs around a clock change. A job scheduled inside the skipped hour will not fire that day, and one inside the repeated hour may fire twice.
Cron, time zones and the twice-yearly surprise
A cron expression describes a wall-clock time, not an instant, so its meaning depends entirely on the zone the daemon is running in. Classic Unix cron uses the system zone, which on a server is often UTC while the person who wrote the schedule was thinking in their own local time. A job meant for 9am local fires at 9am UTC, and nobody notices until it matters.
Daylight saving turns that into two concrete failure modes each year. When clocks spring forward, an hour of wall-clock time does not exist — a job scheduled for 2:30am simply does not run that day. When clocks fall back, that hour occurs twice, and depending on the implementation the job may run twice. If it is a billing run or a report, both outcomes are bugs.
The standard mitigation is to run schedulers in UTC and do any local-time reasoning inside the job. UTC has no daylight saving, so every wall-clock time exists exactly once and the schedule is stable. The cost is that a job which genuinely must run at 9am local in a DST-observing zone now needs logic, because its UTC time moves twice a year.
Modern schedulers — systemd timers, Kubernetes CronJobs, most cloud schedulers — let you attach a zone to the schedule and handle the transitions with defined semantics. Where that is available, use it and read the documentation on what it does with the skipped and repeated hours, because the behaviour differs between implementations.
When you'd reach for it
Verifying a new schedule
Confirm an expression fires when you intended before you ship it.
Debugging a job that ran late
Check whether the scheduler's zone explains an unexpected fire time.
Auditing before a clock change
Find jobs scheduled inside the hour that is about to be skipped or repeated.
Migrating servers
See how a schedule's behaviour changes when the host zone does.
Reviewing someone else's crontab
Read an unfamiliar expression as concrete upcoming times.
Coordinating dependent jobs
Check that an upstream job really finishes before a downstream one starts.
Questions & answers
- Which cron syntax is supported?
- Standard 5-field crontab: minute, hour, day-of-month, month, day-of-week. It supports *, step values like */5, ranges like 1-5, and comma lists like 0,30.
- How is the time zone handled?
- Cron jobs fire on the server's wall clock, so you choose that zone and the tool evaluates matches against it — daylight-saving shifts included — then also shows each run in your local time.
- How do day-of-month and day-of-week combine?
- Following Vixie cron: if both are restricted, a run fires when either matches. If only one is restricted, only that one applies.