ical-recurrence: add scenario calendars for the recurrence fixes
Eleven calendars covering the bugs fixed over the preceding commits,
through the golden scenario harness rather than through recurEvents
directly. That is a different path: it parses a whole VEVENT or
VCALENDAR from text, and it renders the resulting occurrences back out
and reads them again, so it exercises the property rendering and the
golden format as well as the recurrence itself.
These all pass. Each bug already has its own regression test in the
commit that fixed it, so there is nothing red here and no accompanying
change; this is coverage, laid out the way the recurrence fixtures in
this package already are.
event/hourly HOURLY, which used to throw
event/rdate-period-duplicate one instance per start, RDATE winning
event/yearly-bysetpos BYSETPOS over the whole year
event/yearly-byweekno-wkst COUNT with a Sunday week start
event/yearly-byweekno-53 week 53 of a 52 week year
event/monthly-bysetpos-limit BYSETPOS not narrowed by the limit
event/weekly-bysetpos-limit the same, weekly
calendar/zoned-until-utc a UTC UNTIL on the last instance
calendar/exdate-other-timezone an EXDATE in another time zone
calendar/exdate-utc-zoned-event an EXDATE in UTC
calendar/zurich-dst-gap an instance in a daylight saving gap
Every golden was checked against a separately worked out expectation
rather than taken on trust from --golden-start. Four of them would have
been wrong before the fixes, and say so: yearly-bysetpos would have had a
spurious 15th of July 2020, yearly-byweekno-53 a spurious 30th of
December 2019, and the two BYSETPOS-at-the-limit ones a spurious 1st of
January 2023.
zurich-dst-gap is the one worth reading. COUNT=4 yields four instances
with the 27th of March missing, so a skipped nonexistent local time does
not use up one of the count, which is what leapdays.ics has always
relied on for the invalid-date half of the same requirement.