[harshreality]

I take it that your position is: cron works for me, so why migrate to another system that uses its own "weirdo" syntax. Mine is: why not migrate since they're both "weirdo" syntax, and systemd's is at least based on ISO8601 and has integration with other systemd features.

Nobody is all that happy with cron's limitations. That's why there are so many variants, with varying features. When a variant has more than 5 fields, the syntax becomes ambiguous... not to a parser, but to whoever's reading and writing the lines, unless they already know the exact cron variant in use. Google, the one large cloud provider that seems to have stuck with basic cron syntax without quartz-scheduler extras, even invented their own pseudo-natural-language scheduling syntax to fill in for features cron lacks, or for people who don't like cron syntax.

Systemd's is definitely novel, but as I keep repeating, it's ISO8601 + cron. An alternative would be some extension to ISO8601 interval syntax, but that looks clunky and has probably never been used outside of niche applications for data interchange, probably inside xml files; it's used in https://docs.cibseven.org/manual/2.0/reference/bpmn20/events... (syntax at https://en.wikipedia.org/wiki/ISO_8601#Durations ). I think systemd's syntax is better than that.

The direct benefits, even if cron syntax suffices: Calendar timers are integrated with systemd, with all its process-management capabilities[1]. Unifying to systemd timers also avoids duplication of functionality ("is this scheduled process managed by systemd or cron?"). Cron doesn't let you `systemctl list-timers --all`. You'd have to grep through cron logs, possibly (and ironically) using journalctl, or have those logs already in a management dashboard, and that still doesn't let you see the next time the timer would fire. Cron also doesn't let you beta-test cron lines like you can with `systemd-analyze calendar --iterations 10 "Fri *~8..14/1"`

There's even a systemd-cron translator/generator that's in the official debian/ubuntu repos, and in Arch's AUR of course, which avoids the need for system cron but allows you to retain existing crontabs by importing them as systemd timers. They won't be quite as well integrated because it uses defaults for task names and other parameters, but the crontabs get run... without cron.

[1] https://unix.stackexchange.com/a/281203

[simoncion]

> I take it that your position is: cron works for me, so why migrate to another system that uses its own "weirdo" syntax.

I'll repeat my opinion, as expressed in my first post:

  To do nontrivial scheduling you'd use the entirely-obvious-and-intuitive syntax described at [0]. For example:
  
    Mon,Fri *-01/2-01,03 *:30:45
  
  Who'd ever want to go back crontab format for nontrivial scheduling? [1]

  [0] <https://www.freedesktop.org/software/systemd/man/latest/systemd.time.html#Calendar%20Events>
  [1] This question is sarcasm. SystemD is often like this... dead simple things look dead simple, but complex things are -if they're possible at all- at least as complex as they are everywhere else.

[harshreality]

System cron can't implement your example, so I guess what you say is technically true... EINVAL is more obvious and intuitive than <systemd calendar incantation>. Cron just can't do what you want.

You keep saying systemd calendar format is "at least as complicated", but it seems to me the converse is true. Simple cases are simpler to represent in systemd because fields are optional in various circumstances; complex cases, where they can be implemented in system cron at all, look equivalently complex. Removing the weekday constraint, rounding to minutes, and removing the star for year since it's optional:

    31 * 01,03 01/2 *
    01/2-01,03 *:31

What's the point of your gripes? Would you really suggest to someone, who has a systemd-based distro, to spin up systemd-cron or cronie and keep writing crontabs? Do you have some specific complaint about systemd calendar syntax that you think could be improved?