Properly adjust invalid dates in RecurrenceRule enumeration #1077
Conversation
This file contains 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
In recurrence rules without a strict matching policy, we'd sometimes come across
dates which don't exist (such as February 29, 2009). When adjusting these dates,
we were passing unadjusted date components. That resulted in adjusted dates with
the highest unspecified component different than the original date. For example,
adjusting February 29, 2009 to match components {month: 2, day: 29} would result
February 29, 2012, instead of Match 1 or February 28 of the same year.
Adjusting the date components (that is, setting the year to 2009 for the example
above) fixes this. This is what we already do in Calendar.dates(byMatching: ...)
|
@swift-ci please test |
itingliu
approved these changes
Dec 10, 2024
| let rangeStart = Date(timeIntervalSince1970: 946684800.0) // 2000-01-01T00:00:00-0000 | ||
| let rangeEnd = Date(timeIntervalSince1970: 1262304000.0) // 2010-01-01T00:00:00-0000 | ||
| var birthdays = rule.recurrences(of: rangeStart, in: rangeStart..<rangeEnd).makeIterator() | ||
| // ^ The initial date here does not matter, since the rule will change the month and day |
There was a problem hiding this comment.
I thought the initial date does matter in a sense -- it does affect hour, minute and second of the results. Perhaps rephrase this comment to clarify that the initial date does not affect specifically the month and day of the results?
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
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.
In recurrence rules without a strict matching policy, we'd sometimes come across dates which don't exist (such as February 29, 2009). When adjusting these dates, we were passing unadjusted date components. That resulted in adjusted dates with the highest unspecified component different than the original date. For example, adjusting February 29, 2009 to match components {month: 2, day: 29} would result February 29, 2012, instead of Match 1 or February 28 of the same year.
Adjusting the date components (that is, setting the year to 2009 for the example above) fixes this. This is what we already do in Calendar.dates(byMatching: ...)