By: Tom Sydney Kerckhove <syd@cs-syd.eu>
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.