Cron schedules, daylight saving and time zones
A cron expression describes calendar fields, but a scheduler also needs a clock and a time zone. Before relying on a schedule, check both the expression and the implementation that will execute it.
Read the five fields
A common Unix cron form has five fields, in this order:
minute hour day-of-month month day-of-weekFor example, 30 9 * * 1-5 means minute 30 of hour 9, every month, on weekdays in implementations that use the conventional five-field interpretation. It does not mean “every nine hours”; the hour field is a wall-clock hour.
*means every allowed value in that field.5selects one value;1-5selects an inclusive range in common implementations.*/15is commonly used for every 15th minute within that field.- Names such as
MONand special fields vary by cron dialect. Verify them in the scheduler’s manual.
Day-of-month and day-of-week can surprise you
In traditional cron behavior, when both day-of-month and day-of-week are restricted (not *), a job runs when either field matches. For example, a schedule specifying the 1st day of the month and Monday can therefore run on Mondays as well as on the 1st, not only when the 1st is a Monday. This rule is easy to miss and should be confirmed for the cron implementation in use.
Which time zone does cron use?
Many system cron daemons evaluate schedules using the machine’s configured local time, but containers, managed schedulers and application libraries may use UTC or a per-job setting. Do not infer the zone from the person editing the crontab. Check the service documentation and the machine or container configuration.
If a task must run at one exact global instant, a UTC schedule is often easier to reason about. If it must run at a local business time—say 09:00 in Zagreb—define which IANA time zone is authoritative and check whether your scheduler supports it directly.
Daylight-saving transitions
Local wall-clock time can jump forward or repeat when daylight-saving rules change. A job scheduled during a skipped hour may not run at the expected local time; an hour that occurs twice may be handled differently by different schedulers. There is no single portable answer for all cron products. For critical jobs, read the specific implementation’s DST policy, prefer UTC when the business requirement permits it, and make the job safe to run more than once.