Hashed cron expression support

[kbond]

Hello, curious if there's any interest in adding support for "hashed" cron expressions. This is a feature I ported to PHP from Jenkins in zenstruck/schedule-bundle (this link describes the feature).

If interested, how should it be added? One thing it needs is a context string to use to make the resulting expression deterministic:

new HashedCronExpression('# #(0-2) * * #', 'some context');
new HashedCronExpression('# #(0-2) * * #', 'different context'); // generates different expression than above

[kbond]

A great improvement on my code by @TimWolla here: symfony/symfony#49792 (comment)!

[TimWolla]

Related: https://news.ycombinator.com/item?id=35862837

[kbond]

Interesting, so for my example above, the new syntax would look like?

new HashedCronExpression('~ 0~2 * * ~', 'some context');

In OpenBSD, I think the time is randomized for each run (not deterministic) or am I wrong on that?

[TimWolla]

Interesting, so for my example above, the new syntax would look like?

Yes, this is my understanding. It would now also allow 0~29/5 * * * * (every 5 minutes during the first half of an hour, but with a random offset of 0-4), whereas your syntax does not allow it to my understanding.

In OpenBSD, I think the time is randomized for each run (not deterministic) or am I wrong on that?

Not sure, I don't use it. I came across the HN submission and thought I'd share it, because it is related.

[dragonmantank]

The problem with "jitter" in this library is that because it has no state, there's no guarantee that a cron will validate, nor to stop it from running multiple times within the jitter window.

In this case, wrapping this library and extending is probably actually the best case. Then an individual task-running system can handle that any way they want (currently cron-expression should just be viewed as a validation tool, not specifically task running).

I'm happy to leave this open if we get a decent traction, because I'm slowly moving things over to phpixie-cron where it will be easier to group more of these over-the-top implementations.

[TimWolla]

The problem with "jitter" in this library is that because it has no state, there's no guarantee that a cron will validate, nor to stop it from running multiple times within the jitter window.

The suggestion would just be an “expression generator” that takes a pattern and a seed and returns a deterministic expression. The purpose would be generating different execution times within a fleet of servers, without storing state.