Open gauravashtankar opened 3 years ago
Unfortunately this problem relates to the format itself, please see this section on Wikipedia:
Note that frequencies in general cannot be expressed; only step values which evenly divide their range express accurate frequencies (for minutes and seconds, that's
/2
,/3
,/4
,/5
,/6
,/10
,/12
,/15
,/20
and/30
because60
is evenly divisible by those numbers; for hours, that's/2
,/3
,/4
,/6
,/8
and/12
); all other possible "steps" and all other fields yield inconsistent "short" periods at the end of the time-unit before it "resets" to the next minute, second, or day; for example, entering*/5
for the day field sometimes executes after1
,2
, or3
days, depending on the month and leap year; this is because cron is stateless (it does not remember the time of the last execution nor count the difference between it and now, required for accurate frequency counting—instead, cron is a mere pattern-matcher).
It will be nice to introduce a 'warning' for such cases. A daily (an external) user is not aware abot this specific limitation and thus expect coorect results. For example: if the user have passed a not accurate frequencies (according to values from that article), do log info-message with suggestion of this limitation (maybe add this link to Wiki article). I think that lot of users have still faced to this issue eventually.
I think adding it to the docs is sufficient, and as far as I can see it has been explained in the docs as
Pay attention that /24 is just equivalent to 0,24,48 and /24 in minute field doesn't literally mean every 24 minutes it means every 0,24,48 minute.
When cron expression is set to run job at every 30+ mints, for example "/40 *", it shows next occurrences as
8/6/2021 3:40:00 AM 8/6/2021 4:00:00 AM 8/6/2021 4:40:00 AM 8/6/2021 5:00:00 AM 8/6/2021 5:40:00 AM 8/6/2021 6:00:00 AM 8/6/2021 6:40:00 AM 8/6/2021 7:00:00 AM 8/6/2021 7:40:00 AM 8/6/2021 8:00:00 AM
It's not continuing the 40 mints gap between the executions.