These are wall-clock times. A cron schedule fires when the server clock reads the time, whatever the offset that day — the Philippines has not observed daylight saving since 1978, so it does not shift here.
Cron has five fields: minute hour day-of-month month day-of-week. That part is easy. The hard part is how the two day fields combine.
When both day-of-month and day-of-week are restricted, cron fires when EITHER matches — not when both do. So 0 0 13 * 5 is not Friday the 13th. It is midnight on the 13th of every month and midnight every Friday: roughly sixty runs a year, not one or two.
Nothing in crontab warns you. The job you thought ran annually quietly runs sixty times.
The other trap is a day that does not exist. 0 0 31 * * fires seven times a year — cron skips the shorter months rather than moving the run to the 30th. For the last day of the month, schedule it daily and test the date inside the job.
No, and this is the most misread rule in cron. When BOTH the day-of-month and day-of-week fields are restricted, POSIX cron fires when EITHER matches — not when both do. That expression runs at midnight on the 13th of every month AND at midnight every Friday: roughly sixty runs a year rather than one or two. To require both conditions, restrict one field and test the other inside the job itself.
Because six fields means Quartz or Spring, which put SECONDS in front. Unix crontab takes five, starting at the minute. The two are not interchangeable: “0 0 12 * * ?” is noon in Quartz and nonsense in a crontab. Dropping the leading field to make it fit would produce a plausible, wrong schedule, so it is refused with the reason instead.
Nothing — cron skips it rather than moving the run to the 30th or the 1st. “0 0 31 * *” fires seven times a year, and “0 0 30 * *” never fires in February. If you want the last day of the month, schedule it daily and test the date inside the job.
Both, in every real cron. Day-of-week runs 0 to 7 with Sunday at each end, which is why “* * * * 0” and “* * * * 7” are the same schedule. This accepts either and folds 7 onto 0.
They are wall-clock times, which is how cron itself works: “0 3 * * *” means “when the server clock reads 03:00”, whatever the UTC offset is that day. So the list is correct for whatever zone your server is in. On a server that observes daylight saving, a time inside the skipped hour never runs and a time inside the repeated hour may run twice — that does not arise in the Philippines, which has not observed DST since 1978.
Those are Quartz extensions: L is “last”, W is “nearest weekday”, and # is “the nth of the month”. No Unix crontab understands them. Reading “5L” as plain 5 would give you a run list that is confidently wrong, so it is named and refused instead.
Runs entirely in your browser; nothing is transmitted. Standard five-field Unix cron only — Quartz syntax (six fields, L, W, #) is named and refused rather than guessed at. Run times are wall-clock times, which is how cron itself works. Nothing you type here is sent to our servers — the calculation runs entirely in your browser.
