| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
RFC 5545 3.3.10 bounds a recurrence inclusively: when UNTIL lines up with the
recurrence, that date is the last instance. The expansion loops guarded on
calendar-sync--before-date-p, a strict comparison, so the instance landing
exactly on UNTIL was dropped. Every bounded series silently lost its last
meeting from the agenda. A series whose UNTIL equals its start date lost the
only instance it had and vanished.
I added calendar-sync--date-on-or-before-p beside --before-date-p and swapped
the three UNTIL sites: the simple-recurrence loop feeding daily, monthly and
yearly, plus both weekly checks. --before-date-p is unchanged, since a date is
still not before itself.
The two UNTIL property tests asserted the wrong invariant. They required every
occurrence to fall strictly before UNTIL, the exclusive reading the RFC
contradicts, so they pinned the defect they should have caught. The property is
now on-or-before. An upper bound alone can't catch a dropped occurrence, so I
added one asserting the series reaches its UNTIL date.
Reverting the fix failed three daily tests and one property test, and no weekly
ones. The weekly loop was fixed but unguarded, so it has its own test now.
The comparison stays date-granular, matching --date-to-time. An UNTIL carrying a
time of day earlier than the event's start will include that final instance
where the RFC would exclude it. Making it datetime-precise means reworking
--date-to-time and the timezone conversions feeding it, a much larger change
than this bug warrants.
|
