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

Everything else is simpler. You don't have to count fields to figure out whether you're dealing with a day vs a month, or an hour vs minute, no matter how the fields are aligned or how long or complex they are. You can scan left and right and look for space and dash and colon to figure out where you are. The formats for time and date are distinctive and ubiquitous. You don't have to guess what you're looking at when you just see one of them in isolation.

Very little follows from cron's format. You have to learn which fields are which for your particular implementation: does it include seconds? You have to learn the bizarre interaction between day and weekday, to do something non-trivial with them. You have to carefully keep track of which field you're in because you can't determine that from neighboring syntax. The visual clutter, if you want to call it that, of systemd's iso8601-based syntax only applies if you're doing complicated rules. In the vast majority of cases it would simply be an ISO8601 timestamp with various values replaced with *'s, and at most one /.

That first impression you had is what I thought too, before diving into it for my previous replies. But no, cron logic is that day and weekday are ORed. It lets you do clever things like run a script on the 1st and 15th of every month, AND on mondays, all in one line. I don't think I've ever seen such a thing in the wild. I'd go so far as to say it's stupid, because it's likely to be misinterpreted if anyone did use it that way. All the other fields are ANDed. I would say that systemd's AND logic is better... and more consistent, which is your own acceptance criterion.

It ultimately doesn't matter "for real", because almost nobody without some horrific legacy system to integrate with would need to use anything more than lists, ranges, and increments. There's a reason nobody's added these features to system crons. Clever trigger times for events that don't really need to be triggered at clever times... sure, but lacking that capability wouldn't change anything, the trigger would just be a more boring one.

Events like "last Friday of the month" or "nearest weekday to the 1st of the month" or even "Friday the 13th" are more for business logic, not system crontabs.

Systemd enables cleaner, simpler syntax for common cases. Instead of "59 23 * * *", simply "23:59". Instead of "0 0 * * sun[day]", simply "sun[day]". 1st of the month and don't care exactly what time? Instead of "0 0 01 * *", simply "*-*-01".

Systemd started with the principle that they wanted to accept ISO8601 timestamps, then extended that with lists, increments, ranges. They developed that into a superset of basic cron capabilities, while maintaining similar syntax as best they could for increments and lists; they diverged for ranges and nth-from-last because those conflicted with the - date separator. They repurposed the little-used ~ cron randomization operator in the process. (systemd uses a separate RandomizedDelaySec line for that, which is also arguably superior because it randomizes per trigger, not on initial load of the timer)

The alternative is how AWS does it. They have separate cron() and at() syntax. at() takes timestamps. cron() takes cron+quartz syntax, mangled to remove seconds. They also have rate(value units), because apparently cron syntax is too complicated for most people. I'm sure in theory they did it to support "every 7 minutes" cases. I bet if you surveyed actual rate() AWS schedules, 99% would be cases that evenly divide a larger time unit, and could therefore be implemented with cron().

Cron syntax is more of a mess than I thought. While basic system crons don't support any advanced features, AWS and Cloudflare have adopted LW# capabilities, derived from quartz job scheduler syntax (Cloudflare references quartz explicitly). Quartz has extra fields for seconds and year (year optional, so it must go last, which breaks d m Y sequencing) so its syntax has 6 or 7 fields vs the standard 5. CF uses 5 fields, no seconds or years. AWS uses 6 fields, years but not seconds. Whenever you interact with cron-derived systems, you have to remember not just whether they support quartz-style syntax, but whether they support seconds and/or years. Is that really simpler?

The one feature I found interesting, "W", may not work the way I anticipated according to quartz's documentation. I thought "nearest weekday to the 1st of the month" might be useful because it maps to some billing cycles, but quartz (at least through 2.3) couldn't do that. The 2.3 docs say that 1W, if the 1st falls on a Saturday, triggers on the 3rd because it won't jump backwards over a month boundary. That was my only interesting use case for "W". Systemd does everything else, though it requires more verbosity in some cases, it's simpler in many others. 2.4/2.5 are from the last couple of years, and their docs are restructured and don't mention that, so maybe it was finally fixed? I'm not about to install java crud to test.

I didn't find the *-*~01 syntax that strange (last day of every month). The "fri *-*~07/1" syntax for "last friday of every month" is what I found magical, but it makes sense now that I've thought about it more.

What would you prefer for 3rd friday of the month? Cron (5-field, quartz syntax)

    0 0 ? * fri#3  (special syntax is needed because cron uses logical-or to combine day and weekday fields)

    fri *-*-15..21 (works because systemd day and weekday are joined with logical-and)

[aws] https://docs.aws.amazon.com/scheduler/latest/UserGuide/sched...

Isn't this one of the better uses of AI? Any librarian would have knowledge gaps and bias. Librarian-provided info is best-effort and not considered perfect. They're librarians, not subject matter experts. An AI could give (and cache, since books don't change) summaries of any book, and compare them, far better than a librarian except for niche areas a particular librarian might have read themselves.

Nobody's prevented from using cron instead of systemd timers. The significant differences in typical relatively simple cases are ordering:

cron: M H d m Y DOW

systemd: DOW Y-m-d H:M:S [each part optional, with *, *, and 00:00:00 defaults]

And then, because - is taken, ranges use .. in systemd. Aside from that, it's mostly the same for typical cases of simple periodic timers. Even x/n and x-y/n for steps work similarly. Syntax for complex cases start to diverge, for jitter or special numerically-irregular DOW or DOM or multiple non-periodic times.

In your example, adding more spaces between the date and time parts would make it more visually digestible. There's also the .. range operator which jippity strangely didn't use for the month field even though it did for the hours field.

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.

There's also novelWriter which is also python but at least it uses pyqt.

You're right, that was incorrect. I've discovered my error. I should have deleted the filesystem instead of the database.

That hasn't solved the problem either. Let me examine my options. I see there are cloud services involved in this project. Decommissioning them will solve the problem.

What it fails to account for is that today's internet is qualitatively different from the pre-social-media, pre-smartphone internet. The vast majority of the internet audience, too, is qualitatively different. Incentives are misaligned for an average parent who might want to keep a tight leash on smartphone internet access for their kids, when attempting to do so will generate fierce opposition from their kids and leave them socially out of the loop.

I don't understand why a storage tank for this stuff doesn't have an injection port, independent from any other pipes or valves, that could be used to add an inhibitor. Maybe it does and it's broken (clogged with PMMA from the reaction) as well?

The Snowden leaks revealed that the NSA is flummoxed on how to tackle variable character lengths. However, they've cracked rot26 using custom ASIC supercomputers, so it should be considered insecure even though it's twice as good as rot13.

I hope nobody leaves that page open on a metered or capped network connection.

I'm surprised github hasn't suspended the page.

Are AI researchers so used to burning through compute and network resources that they don't stop to think about a webpage that will autoplay and loop multiple HD videos?

Extended questioning, a pat-down or other physical search, and cursory search of luggage for physical contraband (all at international port of entry, of course) is still not the same as scrolling through someone's media gallery and files.

Correction to my previous (GP) post above: The miranda warning and waiver of rights was after the consensual search of his phones. That could be very important. If law enforcement suspects you of a specific thing enough to want to search your phone, but they don't have enough evidence that you're a suspect who merits a miranda warning, what are they doing asking to search your phone?

While everyone can save themselves from this scenario by saying no to searches, it's obvious that this was a fishing expedition. I think EFF should (but probably won't) prevail on the theory that phones have too much of our lives to be allowed to be searched like that, even voluntarily.

Suppose cops went door to door asking to enter and take a look around for contraband. I doubt courts would uphold cops' power to ask to look at people's phones (maybe asking for a cup of coffee while they do it). Regardless of whether the individual consents, it's too much of a breach of privacy without any particular reasonable suspicion of anything in particular.

Case law seems to focus on length and intrusiveness of temporary detention. I'd say this was too lengthy, too specific, and too intrusive for the measly "evidence" (coming from Colombia, and a FinCEN report that didn't allege any impropriety, just financial transfer(s) to a minor) they purported to have.

It's possible this was parallel construction.