Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

GetOccurrences -- Issue #39

Open
gauravashtankar opened this issue Aug 6, 2021 · 3 comments
Open

GetOccurrences -- Issue #39

gauravashtankar opened this issue Aug 6, 2021 · 3 comments

Comments

@gauravashtankar
Copy link

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.

@odinserj
Copy link
Member

odinserj commented Aug 6, 2021

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 because 60 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 after 1, 2, or 3 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).

@Sergio1C
Copy link

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.

@jbennink
Copy link

jbennink commented Dec 7, 2022

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Development

No branches or pull requests

4 participants