A production-minded checklist for validating five-field cron expressions and Unix timestamps.
Name the cron dialect
Classic cron has five fields: minute, hour, day of month, month, and day of week. Some libraries add seconds or years and support extensions such as ? or L. Verify field count and engine documentation before moving an expression between platforms.
`0 3 * * *` usually means 03:00 daily, but the time zone is external to the expression. Record that hidden assumption with the job configuration.
Day-of-month and day-of-week semantics
Many engines do not combine restricted day-of-month and day-of-week fields with a simple AND. A job may run when either matches. Test expressions such as 'the first of the month and Monday' on the production engine.
Validate ranges, lists, and steps with small examples. Human-language explanations are useful review aids, but engine tests remain the authority.
Time zones and daylight saving
Local-time jobs can be skipped or duplicated around DST. Schedule critical work in UTC where practical and convert only for display. If an operation must happen once, use idempotency keys, a last-run record, and an explicit retry policy.
- State the time zone in configuration.
- Test both DST transitions.
- Make critical jobs idempotent.
Make Unix time observable
Specify seconds or milliseconds in field names and schemas. Log the raw value together with its ISO 8601 UTC representation. Negative values may be valid before 1970; unexpectedly huge values often reveal a unit mismatch.
Generate at least the next five occurrences before deployment. In production, measure scheduled time, actual start, finish, and outcome—a scheduler that fails silently is not reliable automation.
Visual suggestion: A timeline comparing local time, UTC, the cron plan, and actual execution logs. This article is general information, not legal or security advice.