It is succesfully flying 51 year. And will work next 50 years. Systemd probably will changes syntax in next 2 years. Modern development mindset: if tool is not rewritten last month - it is outdated and we need to reinvent it. Probably using blockchanin and AI.
I don't love cron's time format - it's easy to make mistakes - but one-line, one file configuration is simple in a nice way. I bet we could make a cron that was easier but still simple.
Crontab could be confusing at first glance but 100 lines (literally) of man page have everything including examples. In my exerience they covers 99% of use cases unless you need something REALLY fancy.
And you have cron on every system including BSD and not sure but probably also AIX/Sun/etc. It is universal and everyone knows about it. If your server doing something weird your probably will check crontab, not some obscure systemd subsystem almost no one knows about.
Instead using standart solutions (POSIX by the way) systemd again found NIH problem with cron and added one more tool in init combain.
My point was purpose built doesn't mean its the best tool for the job.
As for the rest of the drivel: so what it was used for a long time. That just means it was pretty good. That doesn't mean it has to stay forever, just that a new contender should do things better.
Systemd timers address real shortcomings of cron.
Your argument boils down to: everyone should be stuck with shortcomings of the early days of computing because you don't like new things.
> My point was purpose built doesn't mean its the best tool for the job.
But you are agree cron is pretty good so it seems analogy with flying brick does not work here.
> Your argument boils down to: everyone should be stuck with shortcomings of the early days of computing because you don't like new things.
I would say: do not fix it if it's not broken. You need a really serious reason to change a good software to one with dubious quality and future. And without portability.