Cron schedules need a timezone

Read the five fields in order

The supported grammar is minute, hour, day of month, month and weekday. Asterisk means every value, a comma forms a list, a dash forms a range and a slash forms a step. The builder intentionally rejects Quartz syntax, seconds, named fields and macros so the preview has a narrow, visible contract.

For example, 0 9 * * 1-5 means 09:00 Monday through Friday in the chosen timezone. It is not inherently 09:00 UTC. Copying it into a scheduler whose zone differs will change the actual execution time.

*/15 * * * *   every quarter hour
0 9 * * 1-5    weekday mornings
0 0 29 2 *     leap-day midnight

Inspect transitions in UTC and local time

An IANA timezone such as America/New_York carries seasonal offset rules. In spring, some local wall-clock times do not occur; in autumn, some occur twice. The parser applies its own DST behavior, which may not match every cron daemon or hosted scheduler.

Use the upcoming-date preview to compare zoned dates with their UTC instants. For critical jobs, reproduce spring and autumn transitions with the exact scheduler you deploy. A UTC schedule avoids seasonal UTC offsets but changes its local wall-clock hour when daylight time changes.

Two day fields can widen a schedule

This builder follows cron-parser OR semantics when both day of month and weekday are restricted. An expression can run when either field matches, rather than requiring both. Do not use it as an implicit “first Monday” rule.

The tool previews dates only. It does not run jobs, retry failures or ensure exactly-once execution. Production tasks should be idempotent, with explicit monitoring and a plan for delayed or duplicated invocations.

Continue reading

• A sample is not a data contract
• Choose an ID for the job