Cron Daylight Savings Fixer – Prevent Duplicate and Missing Job Runs

Around DST changes, a job scheduled in local time can land in an hour that does not exist (clocks spring forward) or that happens twice (clocks fall back). What the scheduler does then is not universal: cronie runs a fixed-time job from the skipped hour right after the change and does not run it twice in the repeated hour; AWS EventBridge Scheduler skips the run in the skipped hour and runs once in the repeated hour; other schedulers document it differently, or not at all. Either way the job no longer runs at the time you wrote. A cron expression evaluated in UTC removes DST from the picture.

The problem is that most cron daemons evaluate schedules in the server's local timezone. A job scheduled at 30 2 * * * on a server in US/Eastern will behave differently depending on whether DST is in effect. During the March "spring forward" transition, 2:30 AM never occurs — the clock jumps from 2:00 AM directly to 3:00 AM — so the job is skipped. Writing the cron expression in UTC hours removes the dependency on local timezone entirely.

# Local time expression — affected by DST
30 2 * * *    # "run at 2:30 AM" — 2:30 does not exist on the spring-forward
              # day (US/Eastern: 8 March 2026); what happens depends on the scheduler

# UTC equivalent for US/Eastern (EST = UTC-5, EDT = UTC-4)
30 7 * * *    # "run at 07:30 UTC" — always runs, never duplicated
              # Note: UTC offset for Eastern changes between EST and EDT seasons
              # Use a fixed UTC time that avoids the ambiguous local-time window

What It Is

A cron expression builder generates the five-field or six-field cron syntax that schedules recurring jobs. For DST-related issues, the critical feature is the ability to build expressions in UTC rather than a local timezone — UTC never observes daylight saving time, so a UTC-based schedule is unambiguous and consistent year-round.

For systems that must schedule jobs in local time (because the job represents a business-hours action like "send the 9 AM report"), the builder should also preview the next several scheduled runs, including runs across the DST transition dates, so you can verify the job does not land in the missing or ambiguous hour.

Why Developers Use This

• SRE maintenance windows. Maintenance windows are typically scheduled during low-traffic hours. If the window is specified in local time and falls in the DST transition window, the job either runs during a different actual time or fires twice. Converting the window to UTC avoids the ambiguity.
• Financial and reporting jobs. Jobs that generate daily reports, process end-of-day transactions, or close accounting periods need to run at a consistent real-world time. DST-induced shifts cause them to run an hour early or late, misaligning with the business day they are supposed to close.
• Multi-region deployments. A job that needs to coordinate across clusters in multiple timezones is much easier to reason about when expressed in UTC. All clusters apply the same absolute time, regardless of their local timezone or DST status. See our guide on cron expression examples for the full syntax reference.
• Kubernetes CronJobs. Kubernetes CronJobs use UTC by default. If the expression was written in local time and then copied into a Kubernetes manifest without converting to UTC, the job runs at the wrong wall-clock time for half the year.

Common DST Scheduling Errors

• Scheduling during the repeated hour. In US time zones the hour between 1:00 AM and 2:00 AM on the fall-back date occurs twice. cronie does not run a fixed-time job twice in it, and EventBridge Scheduler runs it once (before the clock goes back); a scheduler that simply matches wall-clock times can run it twice. Schedule outside this hour or use UTC.
• Scheduling during the skipped hour. In US time zones the hour between 2:00 AM and 3:00 AM on the spring-forward date does not exist. cronie runs a fixed-time job from that hour right after the change; EventBridge Scheduler skips it. Quartz's CronTrigger documentation does not say. Check your scheduler, or use UTC.
• Checking a schedule. The EventBridge and Quartz validators take a timezone and a reference date and mark runs that fall in a skipped or repeated hour with the scheduler's documented behaviour. The cron migration guide covers this per scheduler.
• Timezone-aware cron on UTC servers. Cloud servers often run UTC by default. A cron expression written for US/Eastern that is deployed to a UTC server without adjustment runs at the wrong time all year, not just during DST transitions.

How to Use the Cron Builder

Using the DevToolBox Cron Builder to create a DST-safe schedule takes under five minutes.

1. Open the cron builder in your browser. No account, no install.
2. Convert the wall-clock time you want into UTC first — yourself, or with the Timestamp Converter.
3. Enter the schedule using that UTC hour and minute, plus the frequency and day restrictions.
4. Read the next scheduled runs. The builder shows them in your browser's local time, so compare them with the local time you expect.
5. Copy the expression into your configuration file or Kubernetes manifest, and make sure the scheduler evaluates it in UTC.

DevToolBox tools run entirely in your browser — nothing you paste is transmitted to any server.

Frequently Asked Questions

Conclusion

DST-related job failures are predictable and preventable. Scheduling in UTC removes the clock-shift variable entirely; the job always runs at the same absolute time regardless of the season. For jobs that must run at a specific local time, using a timezone-aware scheduler — or explicitly avoiding the ambiguous and missing hours — prevents the silent duplications and skips that only surface in incident reports months later.

If you need a fast cron builder that builds the expression and lists the next scheduled runs, DevToolBox does exactly that. DevToolBox tools run entirely in your browser — no signup, no install, nothing sent to a server.