Skip to content
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

Yearly rrule compliance by the iterator #656

Merged
merged 2 commits into from
May 17, 2024
Merged
Show file tree
Hide file tree
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
6 changes: 5 additions & 1 deletion lib/Recur/RRuleIterator.php
Original file line number Diff line number Diff line change
Expand Up @@ -610,7 +610,11 @@ protected function nextYearly(): void
// If we advanced to the next month or year, the first
// occurrence is always correct.
if ($occurrence > $currentDayOfMonth || $advancedToNewMonth) {
break 2;
// only consider byMonth matches,
// otherwise, we don't follow RRule correctly
if (in_array($currentMonth, $this->byMonth)) {
break 2;
}
}
}

Expand Down
46 changes: 46 additions & 0 deletions tests/VObject/Recur/RRuleIteratorTest.php
Original file line number Diff line number Diff line change
Expand Up @@ -922,6 +922,52 @@ public function testYearlyBySetPosLoop(): void
);
}

/**
* This caused an incorrect date to be returned by the rule iterator when
* start date was not on the rrule list.
*
* @dataProvider yearlyStartDateNotOnRRuleListProvider
*/
public function testYearlyStartDateNotOnRRuleList(string $rule, string $start, array $expected): void
{
$this->parse($rule, $start, $expected);
}

public function yearlyStartDateNotOnRRuleListProvider(): array
{
return [
[
'FREQ=YEARLY;BYMONTH=6;BYDAY=-1FR;UNTIL=20250901T000000Z',
'2023-09-01 12:00:00',
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Note: the existing behavior is that this RRULE creates this event on 2023-09-01 and a recurrence on 2023-09-29, as well as the expected recurrences in June of 2024 and 2025.

IMO it is a separate issue about whether the first occurrence on 2023-09-01 should happen - the issue and this PR are not about that.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yes, having the first day not following the RRule pattern is a violation of the RFC, so maybe a validation error is needed somewhere...

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yes, having the first day not following the RRule pattern is a violation of the RFC, so maybe a validation error is needed somewhere...

We are already being flexible and allowing the first/start day to not have to be a match for the RRULE pattern. And the code schedules that start day. So I suppose we had better keep that behavior, otherwise there would be a BC break.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I like the flexibility here, so +1

[
'2023-09-01 12:00:00',
'2024-06-28 12:00:00',
'2025-06-27 12:00:00',
],
],
[
'FREQ=YEARLY;BYMONTH=6;BYDAY=-1FR;UNTIL=20250901T000000Z',
'2023-06-01 12:00:00',
[
'2023-06-01 12:00:00',
'2023-06-30 12:00:00',
'2024-06-28 12:00:00',
'2025-06-27 12:00:00',
],
],
[
'FREQ=YEARLY;BYMONTH=6;BYDAY=-1FR;UNTIL=20250901T000000Z',
'2023-05-01 12:00:00',
[
'2023-05-01 12:00:00',
'2023-06-30 12:00:00',
'2024-06-28 12:00:00',
'2025-06-27 12:00:00',
],
],
];
}

/**
* Something, somewhere produced an ics with an interval set to 0. Because
* this means we increase the current day (or week, month) by 0, this also
Expand Down