alt Hacker NewsI found the systemd time spec syntax you referenced to be logical and well thought out.
Cron syntax is simpler for the easy cases because cron tries to do less. It ignores years and seconds entirely, and doesn't try to adhere roughly to ISO8601 ordering and field separators, instead using space universally for field separation and euro-style least-to-most significant field ordering. I like ISO8601, so I get along with systemd's style better, despite it introducing slightly more cognitive load.
The only thing that threw me for a loop and seems like "special magic" was
> "Mon *-05~07/1" means "the last Monday in May."
But good luck doing that in one line in cron.
Some cron-style libraries seem to support L/W/# for last / nearest-weekday / nth of month, but I don't know if any system crons do. (cronie? dcron? I don't think so. fcron? bcron? I don't see it there either.) '#' is syntactic sugar for DOW + 7-day range, while L is covered by the above quoted syntax.
If your cron has that kind of syntax, then for a case like "weekday closest to 1st of month", "W" is more convenient than writing 3 systemd timer rules to cover the three cases (weekday day 1, monday day 2, friday last day of month), but that's a big if. Generally you'd have to write 3 rules in cron anyway.
Replies
> I found the systemd time spec syntax you referenced to be logical and well thought out.
I found this amusing when in combination with
> The only thing that threw me for a loop and seems like "special magic" was
but -regardless- a careful reader notes that I never said that the Timer scheduling syntax was illogical or poorly thought out. It's at least as complicated as crontab-style time syntax, which was my entire point.
Related: Not that it's ether part of the core scheduler syntax or necessarily as nice as having it in the core syntax, but my crontab(5) suggests that one can use things like date(1) to get more fine-grained control over the time of execution:
As noted above, skip values only operate within the time period they´re attached to.
For example, specifying "0/35" for the minute field of a crontab entry won´t cause
that entry to be executed every 35 minutes; instead, it will be executed twice every
hour, at 0 and 35 minutes past.
For more fine-grained control you can do something like this:
* * * * * if [ $(expr \( $(date +%s) / 60 \) % 58) = 0 ]; then echo this runs every 58 minutes; fi
0 * * * * if [ $(expr \( $(date +%s) / 3600 \) % 23) = 0 ]; then echo this runs every 23 hours on the hour; fi
Adjust as needed if your date(1) command does not accept "+%s" as the format string
specifier to output the current UNIX timestamp.
> But good luck doing that in one line in cron.
Two options:
or, if your cron supports „L“: