Introduce proposal for Calendar.RecurrenceRule#422
Conversation
| /// a yearly frequency, repeat on the n-th week of the year. | ||
| /// | ||
| /// If n is negative, repeat on the n-to-last of the given weekday. | ||
| case nth(Int, Locale.Weekday) |
There was a problem hiding this comment.
I would suggest adding conveniences like:
extension Weekday {
public static func first(_ weekday: Locale.Weekday) -> Self { .nth(1, weekday) }
public static func second(_ weekday: Locale.Weekday) -> Self { .nth(2, weekday) }
public static func last(_ weekday: Locale.Weekday) -> Self { .nth(-1, weekday) }
public static func secondToLast(_ weekday: Locale.Weekday) -> Self { .nth(-2, weekday) }
}These are much easier to understand that .nth(-1, .wednesday).
There was a problem hiding this comment.
We can keep iterating it during the review period
| /// - Returns: a sequence of dates conforming to the recurrence rule, in | ||
| /// the given `range`. An empty sequence if the rule doesn't match any | ||
| /// dates. | ||
| public func recurrences(of start: Date, |
There was a problem hiding this comment.
I can see use cases for other expand methods:
- Expand N instances (from start) - i.e. use a count instead of a range
- Expand N instances (after instance D) - e.g., give me the next instance (N=1) instance after D
Note sure if these are things you want to include.
There was a problem hiding this comment.
I think both can be achieved using the existing API without a performance cost:
var count = 0
for date in recurrenceRule.recurrences(of: .now) while count < 10 {
count += 1
...
}The range argument is more necessary because it allows to skip calculating recurrences until the start of the range.
| /// dates. | ||
| public func recurrences(of start: Date, | ||
| in range: Range<Date>? = nil | ||
| ) -> some (Sequence<Date> & Sendable) |
There was a problem hiding this comment.
Was there any consideration of using an AsyncSequence here? The number of items in a range could be very large for some frequencies. Also it might be more efficient for "iteratively" generated dates where the whole recurrence calculation does not have to be started for each subsequent range.
There was a problem hiding this comment.
Indeed, some recurrence rules can yield and infinite number of results. Using Sequence allows us to calculate recurrences only when requested, so we don't preemptively calculate the full set at the start of a loop. I don't think there's a need for AsyncSequence here.
This implements most of `Calendar.RecurrenceRule` as it was pitched in swiftlang#422. To do: - Respect RecurrenceRule.matchingPolicy - Respect RecurrenceRule.repeatedTimePolicy - Expand testing
This implements most of `Calendar.RecurrenceRule` as it was pitched in swiftlang#422. To do: - Respect RecurrenceRule.matchingPolicy - Respect RecurrenceRule.repeatedTimePolicy - Expand testing
| /// a yearly frequency, repeat on the n-th week of the year. | ||
| /// | ||
| /// If n is negative, repeat on the n-to-last of the given weekday. | ||
| case nth(Int, Locale.Weekday) |
There was a problem hiding this comment.
We can keep iterating it during the review period
7839480 to
be5c6b0
Compare
Co-authored-by: Tina Liu <49205802+itingliu@users.noreply.github.com>
be5c6b0 to
353f55e
Compare
This commit implements the `Calendar.RecurrenceRule` type first pitched in swiftlang#422. This type models a subset of RRULE as specified in RFC-5545, section 3.3.10. One notable difference is that it doesn't support a frequency of "secondly", as that was not part of the original proposal. It also implements RFC-7529 Non-Gregorian Recurrence Rules and works with any instance of `Calendar`. Recurrences are calculated according to our interpretation of the RFCs. As such, the resulting dates may differ in certain edge cases when compared to other open source implementations.
This commit implements the `Calendar.RecurrenceRule` type first pitched in swiftlang#422. This type models a subset of RRULE as specified in RFC-5545, section 3.3.10. One notable difference is that it doesn't support a frequency of "secondly", as that was not part of the original proposal. It also implements RFC-7529 Non-Gregorian Recurrence Rules and works with any instance of `Calendar`. Recurrences are calculated according to our interpretation of the RFCs. As such, the resulting dates may differ in certain edge cases when compared to other open source implementations.
This commit implements the `Calendar.RecurrenceRule` type first pitched in swiftlang#422. This type models a subset of RRULE as specified in RFC-5545, section 3.3.10. One notable difference is that it doesn't support a frequency of "secondly", as that was not part of the original proposal. It also implements RFC-7529 Non-Gregorian Recurrence Rules and works with any instance of `Calendar`. Recurrences are calculated according to our interpretation of the RFCs. As such, the resulting dates may differ in certain edge cases when compared to other open source implementations.
This commit implements the `Calendar.RecurrenceRule` type first pitched in swiftlang#422. This type models a subset of RRULE as specified in RFC-5545, section 3.3.10. One notable difference is that it doesn't support a frequency of "secondly", as that was not part of the original proposal. It also implements RFC-7529 Non-Gregorian Recurrence Rules and works with any instance of `Calendar`. Recurrences are calculated according to our interpretation of the RFCs. As such, the resulting dates may differ in certain edge cases when compared to other open source implementations.
This commit implements `Calendar.RecurrenceRule.recurrences(of:in:)` as pitched in swiftlang#422. This type models a subset of RRULE as specified in RFC-5545, section 3.3.10. One notable difference is that it doesn't support a frequency of "secondly", as that was not part of the original proposal. It also implements RFC-7529 Non-Gregorian Recurrence Rules and works with any instance of `Calendar`. Recurrences are calculated according to our interpretation of the RFCs. As such, the resulting dates may differ in certain edge cases when compared to other open source implementations.
This commit implements `Calendar.RecurrenceRule.recurrences(of:in:)` as pitched in swiftlang#422. This type models a subset of RRULE as specified in RFC-5545, section 3.3.10. One notable difference is that it doesn't support a frequency of "secondly", as that was not part of the original proposal. It also implements RFC-7529 Non-Gregorian Recurrence Rules and works with any instance of `Calendar`. Recurrences are calculated according to our interpretation of the RFCs. As such, the resulting dates may differ in certain edge cases when compared to other open source implementations.
This commit implements `Calendar.RecurrenceRule.recurrences(of:in:)` as pitched in #422. This type models a subset of RRULE as specified in RFC-5545, section 3.3.10. One notable difference is that it doesn't support a frequency of "secondly", as that was not part of the original proposal. It also implements RFC-7529 Non-Gregorian Recurrence Rules and works with any instance of `Calendar`. Recurrences are calculated according to our interpretation of the RFCs. As such, the resulting dates may differ in certain edge cases when compared to other open source implementations.
This commit implements the `Calendar.RecurrenceRule` type first pitched in swiftlang#422. This type models a subset of RRULE as specified in RFC-5545, section 3.3.10. One notable difference is that it doesn't support a frequency of "secondly", as that was not part of the original proposal. It also implements RFC-7529 Non-Gregorian Recurrence Rules and works with any instance of `Calendar`. Recurrences are calculated according to our interpretation of the RFCs. As such, the resulting dates may differ in certain edge cases when compared to other open source implementations.
This pull request introduces a proposal for a new type,
Calendar.RecurrenceRule, that allows to describe recurring events and calculate future occurrences.