ByDay rule in time zone is incorrect

[GabrielKatz]

My local timezone currently is serialized as

BEGIN:VTIMEZONE
TZID:Europe/Zurich
X-LIC-LOCATION:Europe/Zurich
BEGIN:STANDARD
DTSTART:20171029T030000
RRULE:FREQ=YEARLY;BYDAY=-1SU;BYMONTH=10
TZNAME:CET
TZOFFSETFROM:+0200
TZOFFSETTO:+0100
END:STANDARD
BEGIN:DAYLIGHT
DTSTART:20180325T020000
RRULE:FREQ=YEARLY;BYDAY=4SU;BYMONTH=3
TZNAME:CEST
TZOFFSETFROM:+0100
TZOFFSETTO:+0200
END:DAYLIGHT
END:VTIMEZONE

However, it should be

BEGIN:VTIMEZONE
TZID:Europe/Zurich
X-LIC-LOCATION:Europe/Zurich
BEGIN:STANDARD
DTSTART:20171029T030000
RRULE:FREQ=YEARLY;BYDAY=-1SU;BYMONTH=10
TZNAME:CET
TZOFFSETFROM:+0200
TZOFFSETTO:+0100
END:STANDARD
BEGIN:DAYLIGHT
DTSTART:20180325T020000
RRULE:FREQ=YEARLY;BYDAY=-1SU;BYMONTH=3
TZNAME:CEST
TZOFFSETFROM:+0100
TZOFFSETTO:+0200
END:DAYLIGHT
END:VTIMEZONE

This year, this results in events in one week being displayed one hour early.

From what I can see in the code for VTimeZone.cs, it guesses how the rule applies like this:

ByDay.Add(num != 5 ? new WeekDay(weekday, num) : new WeekDay(weekday, -1));

From my perspective, it would be better to guess that if it is the last sunday in the month, the rule should be accordingly. However, this may have side effects if dailight saving dates are actually defined to be on the 4th sunday in the month.

The correct solution would probably be to retrieve the actual rule from tzdb instead of guessing it, but that probably is overkill.

[gonace]

@GabrielKatz we (as in the company I work for) decided to move on and fork this repository and merged a few bug fixes that have been lying around in this repository for years.

We dislike this but concluded that we had no other choice, you can find this when searching for laget.Ical.Net.