-
Notifications
You must be signed in to change notification settings - Fork 260
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
different execution time behaviour for sec or min lowest field #616
Comments
@dllx thank you for reporting this and for contributing a fix! We will soon merge and release a new version! Thanks! 😎 |
There is also something similarly wrong in the ExecutionTime.isMatch method if the nanos are not zero. |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
I'm experiencing different next execution time behaviour depending if the first field is seconds or minutes.
I think that without any explicit kind of configuration, the seconds field should not behave differently than the minutes field. It's an unexpected inconsistency.
Given
I expect the following, and indeed that's what I observe:
On the other hand, if I add a
seconds
field into the definition likeI expect the following, but the result is different if the seconds field matches and the next second would also match the seconds field! In that case, the nanos field is not set to zero.
By the way, to possibly counter the "strange" expression
3/1
used above, the behaviour can also be seen when using a plain*
for the leftmost cron field.If it's "seconds", then the
nano
part of thenextExecution
time is not set to zero, if it's "minutes", then thenano
(and thesecond
) part of thenextExecution
time is indeed set to zero.The text was updated successfully, but these errors were encountered: