Should skipped events due to DST transitions run the next available hour?

[dragonmantank]

This is related to #179

Behavior of the library is the most complicated when it comes to transition boundaries when time "springs forward" or "falls back", as the saying goes. This has the potential to skip events that call into the dead zone where time does not exist when we jump forward, or run twice when we fall back.

There are a few thoughts on this. vixie cron will attempt to run jobs that are skipped when a less-than-3-hour time correction is noticed. It assumes that when it detects a time skips forward like this, it is more than likely a time transition so will immediately run any jobs in that window. It then does some logic if it notices time jumps backward so as to not run the jobs a second time.

I could not find any logic of this sort in the cronie package, an older POSIX version that vixie-cron evolved from. It seems to take the stance that if a job does not match the configured cron, skip it. (This is a bit of an over-simplification, as I believe it allows you to override the system timezone to get around this limitation through CRON_TZ).

Even systemd's timer system seems to take the match-or-skip stance, and suggests to use different methods to avoid skipped or duplicate runs.

This library currently works more similar to vixie-cron, but not exactly. It will allow hour-matching to the next available hour if it detects a transition. This means that is you have a cron scheduled for 15 2 * * * and a transition jumps past this time, then we will allow the 03 hour to substitute for 02 as a match. In the case of a "fall back", we would still use 03 as a substitute.

It's my thinking that this is wrong and is a bug, and we should adhere to the match-or-skip logic of cronie/systemd. The user should either pick a time that falls outside of a transition window, or add an additional check for the one time a year an event would be skipped.

However, this logic has now existed for more than a year, and I fear would constitute a breaking change. Have we left a bug long enough that people rely on it and it is now a feature? This same thing happened years ago with fixing a step-transition bug around quarters. This impacts the solution to a bug that affects a number of timezones like Europe/London.

So I ask which logic should we use:

1. Validate jobs skipped during a transition to run on the next non-transition hour (usually 03:**)
2. Only validate a job when it exactly matches

[curunoir]

I'm not comfortable with "invisible" rules such as this "3 hour rule" wich seems to me very opiniated. But either way should be well documented in any case.

[dragonmantank]

For this library, we would document that it would run the next available hour (so a skipped 02:30 event would run at 03:30 one time). Any longer than an hour time skip and I wouldn't feel comfortable being as reliable the skip was due to a time change.

The vixie-cron package does document it within the manpage.

At the same time, I dislike unintuitive rules like this. This is one of the reasons I like to base off cronie, it even then it was the one that defined the stupid OR condition for DayofWeek and DayOfMonth interaction.

[SeynovAM]

I think the best way to make this optionally like some setting of CronExpression which can be set through a setter. But I understand that this will force maintain both of versions.

But if you choose between two options then better choice if the first:

Validate jobs skipped during a transition to run on the next non-transition hour

It is better because when application wants something run each day it is not entirely expected when some day will be skipped. And if expected that some cron task should be executed only one time per day it is not expected when it will be executed twice in some of days.

In other option:

Only validate a job when it exactly matches

it is not so easy to fix this on application side. Better if library will try to fix.

But if talking about experience in our application: we try to avoid cron executes between 2 and 3 o'clock. We prevent this on validation level.