Cron timing format & time zones

How cron interprets time

Classic cron runs according to the system clock. It wakes up once a minute, compares the current time to each cron expression, and executes jobs that match.

• Every minute, cron evaluates all scheduled jobs.
• If the minute, hour, and day fields match the current time, the job is eligible to run.
• If both day of month and day of week are restricted, many implementations run the job when either field matches.

That "day-of-month OR day-of-week" rule is a common source of surprises. Our expression pages highlight when it matters and offer Quartz alternatives.

Time zones: local time vs. UTC

Cron jobs are usually defined in local server time, but many cloud schedulers let you pick a specific time zone or default to UTC.

• Linux cron: uses the server's local time zone.
• Kubernetes CronJob: runs based on the kube-controller manager time zone; some distributions add explicit time zone support.
• GitHub Actions: schedules are evaluated in UTC.
• Many hosted schedulers let you choose a time zone per job.

When you schedule "09:00", be explicit about whether that means 09:00 UTC or 09:00 in a specific region (e.g. America/New_York).

Daylight saving time (DST) effects

On days when the clock jumps forward or backward, some times may be skipped or repeated.

• In the "spring forward" transition, a time like 02:30 may never occur – jobs scheduled only at that time might be skipped.
• In the "fall back" transition, an hour is repeated – jobs may run twice if the clock passes through the same time range again.

For critical workloads, it's common to run in UTC and convert times at the application layer, or use a higher-level scheduler that understands calendar semantics.

Related topics