How a Unix cron expression is read
A conventional crontab schedule has five fields in this order: minute, hour, day of month, month, and day of week. An asterisk accepts every value. A comma selects a list, a hyphen selects a range, and a slash applies a step.
15Minute2Hour*Day of month*Month1-5Day of week15 2 * * 1-5 selects 02:15 from Monday through Friday.The day-of-month and day-of-week trap
In common Unix cron implementations, when both fields are restricted, a run can match either field. For example, 0 9 1 * 1 means 09:00 on the first day of a month and on Mondays. It does not mean only Mondays that are also the first.
Example: weekday maintenance
For 15 2 * * 1-5, minute is 15, hour is 2, both date fields allow every value except weekdays, and the job is eligible at 02:15 from Monday through Friday. The UTC instant changes across daylight-saving transitions if the scheduler follows a regional time zone.
What this preview does not prove
The preview searches up to two years ahead. It does not execute a command, monitor a job, or prove that a particular platform accepts the expression. Always check the scheduler documentation and its configured time zone before deployment.
Common questions
Does this support Quartz cron expressions?
No. Quartz normally adds a seconds field and may add a year field, plus tokens that do not exist in ordinary crontab syntax.
Why are the UTC times different after a DST date?
A regional wall-clock time can keep the same hour while its UTC offset changes. That is why each preview row shows both the selected zone and the exact UTC instant.