A single fixed cron time can only hit your target exactly when the offset between the two zones is constant. Wherever daylight saving makes the offset shift, the tool tells you which days the job lands early or late — and by how much.

Why cron and time zones are a pain

A crontab line like 0 2 * * * does not say "at 02:00 UTC" or "at 02:00 my local time" — it says at 02:00 in whatever time zone the cron daemon is running in. Most servers, containers and cloud VMs run that daemon in UTC, so a schedule written while thinking in your local time silently means something else. And because the schedule is a wall-clock time in the server zone, the moment it fires for you depends on the offset between the two zones — which is not constant anywhere daylight saving exists.

The usual fix is to pin the schedule's time zone explicitly. cronie and Vixie-derived crons support a CRON_TZ line at the top of the crontab (e.g. CRON_TZ=America/New_York); systemd timers use UTC unless you set Timezone= on the unit; and many minimal cron implementations ignore CRON_TZ entirely and follow the system zone. Check which one you actually have before trusting any schedule.

What happens at daylight saving time

Twice a year the offset between most northern-hemisphere zones (and between, say, Europe and the Americas, which switch on different dates) changes by an hour. For a cron job that means:

• The time it fires for you shifts. A job at 02:00 in America/New_York is 07:00 UTC in winter and 06:00 UTC in summer — so for someone in London it is 08:00 one half of the year and 07:00 the other.
• Some wall-clock times don't exist. On a spring-forward day the clock jumps (e.g. 02:00 → 03:00), so a job scheduled at 02:30 has no exact moment to run at. cronie runs it at the first valid time after the jump; other schedulers may skip it. Don't schedule anything in the gap window.
• Some wall-clock times happen twice. On a fall-back day 01:30 occurs at two different moments. cronie runs the job once (at the first occurrence), but a job that assumes "01:30 UTC-equivalent" can end up an hour off from what you expect.

The converter above marks every DST transition between consecutive runs, so you can see exactly which run is the first one that lands at the new time.

The "3 AM doesn't exist" problem

If your server zone observes DST and your schedule falls inside the spring-forward gap, the job's behaviour is implementation-defined: it may run an hour late, run immediately, or be skipped. The safe rules: keep recurring jobs out of the gap window (typically 02:00–03:00 local on transition days), or run the schedule in a zone that does not observe DST (UTC is the obvious choice) and convert to local times only for display.

CRON_TZ vs TZ vs systemd — which one wins?

• Classic cron (cronie / Vixie): a CRON_TZ=Area/Zone line in the crontab overrides the daemon's zone for that user's jobs. Some distributions' cron (notably Debian's stock cron) historically ignores it and uses the system zone — verify with man 5 crontab for your distro.
• The TZ environment variable affects what your shell prints, not when the cron daemon fires jobs — a common source of "but my date command says otherwise" confusion.
• systemd timers: OnCalendar= expressions are evaluated in UTC unless the unit sets Timezone= (systemd ≥ 235). A timer that "worked" on a VM and drifted after a migration usually moved between UTC and local-time evaluation.
• Containers: almost always UTC. If your app container runs its own scheduler (Celery beat, APScheduler, node-cron), it follows the container's zone unless the library is told otherwise — Celery, for example, has its own CELERY_TIMEZONE setting.

A practical checklist

• Decide which zone the schedule means and pin it explicitly (CRON_TZ, Timezone=, or scheduler config) — never rely on the server's default.
• Store canonical schedules in UTC; convert to the user's zone only when displaying.
• Use the reverse tool above when a business requirement is phrased in local time ("the report must land in Berlin at 09:00") — it finds the best single server time and shows you the DST days where it can't be exact.
• Test around transitions: run the job (or a dry-run logger) across a spring-forward and a fall-back day and compare the timestamps.
• If you need the local wall-clock time to be exact every single day of the year, a fixed cron time cannot do it across DST zones — you need a scheduler that re-evaluates the wall-clock time per day (systemd with Timezone=, or an app-level scheduler with a zone-aware cron parser).

Cross-check from the command line

GNU date can verify any conversion this page makes:

# What moment is "02:00 in New York" in UTC?
TZ="America/New_York" date -d "2026-11-01 02:00" -u

# What is 07:00 UTC in Sydney?
TZ="Australia/Sydney" date -d "2026-11-01 07:00 UTC"

# Python equivalent (zoneinfo is stdlib since 3.9):
python3 -c "from datetime import datetime; from zoneinfo import ZoneInfo; \
print(datetime(2026, 11, 1, 2, 0, tzinfo=ZoneInfo('America/New_York')).astimezone(ZoneInfo('Australia/Sydney')))"