CronExpression skips days on midnight DST gap#36865
Open
zmovo wants to merge 1 commit into
Open
Conversation
After rollForward, BitsCronField always searched for the next matching bit from zero. When daylight saving creates a gap at the start of a period (e.g. Africa/Cairo), the temporal lands on a non-zero field value and matching from zero could advance an entire period too far, skipping the calendar day. Search from the actual field value in the new period instead, falling back to zero only when no bit matches in that period. Closes spring-projectsgh-36859 Signed-off-by: arno <me@zmovo.com> Co-authored-by: Cursor <cursoragent@cursor.com>
spring-projects-issues
added
the
status: waiting-for-triage
zmovo
force-pushed
the
fix-cron-dst-midnight-gap-36859
branch
from
c52c11f to
ceb9cd9
Compare
bclozel
added
type: bug
bclozel
changed the title
This comment was marked as outdated.
This comment was marked as outdated.
This comment was marked as outdated.
This comment was marked as outdated.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
4 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Fixes #36859.
By default, BitsCronField#nextOrSame delegates to nextSetBit(0) after rollForward, which assumes the field value in the new period starts at zero. When daylight saving creates a gap at the start of a period (for example, Africa/Cairo advancing from 00:00 to 01:00), the rolled-forward temporal lands on a non-zero field value and matching from zero can advance an entire period too far, causing CronExpression#next to skip the calendar day.
This PR searches for the next matching bit from the actual field value in the new period instead, falling back to zero only when no bit matches in that period.
This does not change the existing contract for cron times that fall inside a DST gap: those executions are still skipped rather than deferred or replayed after the transition. The fix only ensures that subsequent valid matches on the same calendar day are still calculated correctly.
It also adds a regression test in CronExpressionTests#daylightSaving for a every-two-hours expression across the Cairo spring-forward boundary.