Cron Timezone Drift Checker
A 5-field cron expression with a timezone — shown as real runs in local time, with the DST trap made visible: where a UTC-anchored schedule lands a different local hour than a zone-anchored one.
Direct Answer
A daily 02:30 job inAmerica/New_York runs at 02:30 local all year when the scheduler is anchored to the zone's wall clock. When the same job is pinned to a fixed UTC time (the common "compute local minus offset once" mistake), it shifts to03:30 local from the second Sunday in March until the first Sunday in November. That shift is the failure mode most cron/DST outages come from.
Worked example: 30 2 * * * in America/New_York
One run per calendar month for 2026. The TZ-anchored column is what a scheduler judging the expression against local time does. TheUTC-anchored column is what happens if the schedule was pinned to UTC in January (02:30 EST = 07:30 UTC): from April through October the job lands at03:30 local instead.
| Run date | TZ-anchored local | Offset | UTC-anchored local | Drift |
|---|---|---|---|---|
| 1 Jan 2026 | 02:30 | UTC-05:00 | 02:30 | Stable |
| 1 Feb 2026 | 02:30 | UTC-05:00 | 02:30 | Stable |
| 1 Mar 2026 | 02:30 | UTC-05:00 | 02:30 | Stable |
| 1 Apr 2026 | 02:30 | UTC-04:00 | 03:30 | Drifts +60min |
| 1 May 2026 | 02:30 | UTC-04:00 | 03:30 | Drifts +60min |
| 1 Jun 2026 | 02:30 | UTC-04:00 | 03:30 | Drifts +60min |
| 1 Jul 2026 | 02:30 | UTC-04:00 | 03:30 | Drifts +60min |
| 1 Aug 2026 | 02:30 | UTC-04:00 | 03:30 | Drifts +60min |
| 1 Sep 2026 | 02:30 | UTC-04:00 | 03:30 | Drifts +60min |
| 1 Oct 2026 | 02:30 | UTC-04:00 | 03:30 | Drifts +60min |
| 1 Nov 2026 | 02:30 | UTC-05:00 | 02:30 | Stable |
| 1 Dec 2026 | 02:30 | UTC-05:00 | 02:30 | Stable |
Why the shift happens — America/New_York transitions
- Sunday 8 March 2026, 03:00 (UTC-05:00 → UTC-04:00) — Clocks move forward 60 minutes
- Sunday 1 November 2026, 01:00 (UTC-04:00 → UTC-05:00) — Clocks move back 60 minutes
- Sunday 14 March 2027, 03:00 (UTC-05:00 → UTC-04:00) — Clocks move forward 60 minutes
Pinned to UTC in January, the job fires at 07:30 UTC every day. While the US is on Eastern Daylight Time (UTC-04:00), 07:30 UTC is 03:30 local — one hour later than the intended 02:30. The local offset in effect at the reference moment is the pin the UTC-anchored column assumes.
Check your own cron expression
Everything computes in your browser. The reference moment is "now": the UTC-anchored column assumes the schedule was pinned to UTC at the offset currently in effect.
Fields: minute hour day-of-month month day-of-week. Supports *, ranges, lists, steps and ? (day-of-month / day-of-week only).
The zone whose local wall clock the cron should be judged against.
| Run | TZ-anchored local | Offset | UTC-anchored local | Drift |
|---|---|---|---|---|
| 1 Sep 2026 | 02:30 | UTC-04:00 | 02:30 | Stable |
| 2 Sep 2026 | 02:30 | UTC-04:00 | 02:30 | Stable |
| 3 Sep 2026 | 02:30 | UTC-04:00 | 02:30 | Stable |
| 4 Sep 2026 | 02:30 | UTC-04:00 | 02:30 | Stable |
| 5 Sep 2026 | 02:30 | UTC-04:00 | 02:30 | Stable |
| 6 Sep 2026 | 02:30 | UTC-04:00 | 02:30 | Stable |
| 7 Sep 2026 | 02:30 | UTC-04:00 | 02:30 | Stable |
| 8 Sep 2026 | 02:30 | UTC-04:00 | 02:30 | Stable |
| 9 Sep 2026 | 02:30 | UTC-04:00 | 02:30 | Stable |
| 10 Sep 2026 | 02:30 | UTC-04:00 | 02:30 | Stable |
Next timezone transitions for America/New_York
- Sunday 1 November 2026, 01:00 (UTC-04:00 → UTC-05:00) — Clocks move back 60 minutes
- Sunday 14 March 2027, 03:00 (UTC-05:00 → UTC-04:00) — Clocks move forward 60 minutes
- Sunday 7 November 2027, 01:00 (UTC-04:00 → UTC-05:00) — Clocks move back 60 minutes
Nonexistent local times (the spring-forward gap) are skipped. A job scheduled inside the fall-back repeated hour runs twice — once per offset — matching standard wall-clock cron.
How to read the drift column
TZ-anchored scheduling evaluates the cron's clock fields against the zone's local wall clock every day. This is what you get with a scheduler set to the business zone, or a cron daemon configured with the right CRON_TZ. The local time stays constant across DST; the UTC time shifts.
UTC-anchored scheduling pins the schedule to a fixed UTC clock time. Many failures start when a developer converts a local time to UTC once — using today's offset — and never revisits it after a DST change. The local time then drifts by the size of the offset change until the next transition.
Rule of thumb: anchor business-hour jobs to a named timezone, not to a UTC time you computed by hand. If a job must run at a fixed UTC instant, say so explicitly and re-check it after every transition that affects the zone.
Read the full cron & timezone guide
When to use UTC, when to use an explicit local timezone, and what to check before every DST transition — the prose companion to this tool.
Open the cron guide →Use the timezone data behind this page
The city dataset, IANA timezones, and API endpoints that power every TimeNowHub tool are documented and freely reusable.
Read the API docs →Frequently Asked Questions
Does the tool support Quartz 6-field expressions?
No, and it says so honestly: this tool parses standard 5-field cron. Quartz-style expressions add a leading seconds column, and silently mis-reading one as 5-field cron is exactly the confusion this page exists to prevent.
What happens when a scheduled time doesn't exist (spring forward)?
The run is skipped, matching standard wall-clock cron. A job set for 02:30 on the day the US jumps 02:00 to 03:00 simply does not fire that day.
Why does the UTC-anchored column depend on when I look at it?
The UTC pin is the zone offset in effect at the reference moment (January in the worked example, "now" in the interactive form). If you pin while the zone is on daylight time, the drift appears in winter instead — the trap is the pin, not the season.