CronExpression skips days on midnight DST gap#36865
Merged
bclozel merged 2 commits intoJun 4, 2026
Merged
Conversation
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.
bclozel
pushed a commit
to zmovo/spring-framework
that referenced
this pull request
Jun 4, 2026
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-36865 Signed-off-by: arno <me@zmovo.com> Co-authored-by: Cursor <cursoragent@cursor.com>
bclozel
force-pushed
the
fix-cron-dst-midnight-gap-36859
branch
from
ceb9cd9 to
a6dc70f
Compare
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. See spring-projectsgh-36865 Signed-off-by: arno <me@zmovo.com> Co-authored-by: Cursor <cursoragent@cursor.com>
This fixes a potential regression introduced by the previous commit. Because the current value was not updated after the temporal was rolled forward, there were new cases where entire days would be skipped. Closes spring-projectsgh-36865
bclozel
force-pushed
the
fix-cron-dst-midnight-gap-36859
branch
from
a6dc70f to
6467fca
Compare
bclozel
pushed a commit
that referenced
this pull request
Jun 4, 2026
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. See gh-36865 Signed-off-by: arno <me@zmovo.com> Co-authored-by: Cursor <cursoragent@cursor.com>
bclozel
added a commit
that referenced
this pull request
Jun 4, 2026
This fixes a potential regression introduced by the previous commit. Because the current value was not updated after the temporal was rolled forward, there were new cases where entire days would be skipped. Closes gh-36865
github-actions
Bot
added
the
status: backported
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.