Cron time zone converter
Ping Clock checks accept cron plus any IANA zone.
Enter a cron expression, the time zone you think in, and the time zone your server runs on. The converter gives you the expression to put in the server's crontab, shows the next runs side by side in both zones, and flags any dates where daylight saving time will shift the job by an hour.
Why this is needed
Most servers and containers run on UTC. Most people schedule in local time. "Run the report at 7 a.m. New York time" is 0 7 * * * in New York, but the server needs 0 11 * * * in summer (UTC-4) and 0 12 * * * in winter (UTC-5). A single classic cron line can't express both.
Your options
Option 1: Accept the drift
Pick one UTC hour and live with the job moving by an hour twice a year. Fine for cleanup jobs and backups.
Option 2: Use a cron that understands time zones
Some cron implementations accept CRON_TZ=America/New_York at the top of the crontab or per line. Kubernetes CronJobs support spec.timeZone in recent versions. Many cloud schedulers let you choose a time zone. Check yours before relying on it.
Option 3: Two lines and a guard
Schedule at both UTC hours and have the script exit unless the local time is the one you want:
0 11,12 * * * [ "$(TZ=America/New_York date +\%H)" = "07" ] && /usr/local/bin/report.shNote the escaped %. Cron treats a bare % as a newline.
Option 4: Run the server in the local zone
It works, but now every log timestamp is local and DST weirdness applies to all jobs on the box. Most teams prefer UTC servers.
The daylight saving traps
In zones with DST, one night a year skips an hour and one night repeats an hour. For a job scheduled in the affected window, roughly 01:00 to 03:00 local time:
- Spring forward: a 02:30 job may not run at all, because 02:30 doesn't exist that night.
- Fall back: a 01:30 job may run twice, because 01:30 happens twice.
What actually happens depends on the cron implementation. Some catch up missed jobs, some don't. The converter lists the exact dates in the next 12 months where your schedule falls into one of these gaps.
The simplest fix: don't schedule important jobs between 01:00 and 03:00 local time in a DST zone.
Zones that change offset by 30 or 45 minutes
India (UTC+5:30), Nepal (UTC+5:45) and parts of Australia use non-hour offsets. Converting 0 9 * * * from Kolkata to UTC gives 30 3 * * *: the minute changes too. The converter handles this.
Day boundaries
Converting can move a job to a different day. A Monday 02:00 job in Tokyo is a Sunday 17:00 job in UTC. If your expression restricts the day of week or day of month, those fields have to shift as well. The converter adjusts them and warns when a single expression can't represent the result.
How monitoring helps
Even with the right conversion, it's easy to get wrong, and it changes twice a year. Ping Clock checks take a cron expression and an IANA time zone, so the monitor knows exactly when to expect a ping, DST included. If the job runs at the wrong hour, or not at all, the expected ping is late and you hear about it.
Questions
Which time zone names are supported?
IANA names like Europe/London or Asia/Dubai. Abbreviations like EST are ambiguous and not accepted.
Does UTC have daylight saving?
No. That's the main reason servers use it.