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

Problems with RRULE when TZID:Europe/Stockholm #533

Closed
gonace opened this issue Oct 25, 2021 · 4 comments
Closed

Problems with RRULE when TZID:Europe/Stockholm #533

gonace opened this issue Oct 25, 2021 · 4 comments

Comments

@gonace
Copy link
Contributor

gonace commented Oct 25, 2021

Hi
I've been scratching my head for a while and can't find any code issues on our side (with that said, I could have missed something). But when we're exporting calendars for the Timezone Europe/Stockholm the CET rule is incorrect.

BEGIN:VCALENDAR
CALSCALE:GREGORIAN
METHOD:PUBLISH
PRODID:-//github.com/rianjs/ical.net//NONSGML ical.net 4.0//EN
VERSION:2.0
X-WR-TIMEZONE:Europe/Stockholm
BEGIN:VTIMEZONE
TZID:Europe/Stockholm
X-LIC-LOCATION:Europe/Stockholm
BEGIN:STANDARD
DTSTART:20191027T030000
RRULE:FREQ=YEARLY;BYDAY=4SU;BYMONTH=10
TZNAME:CET
TZOFFSETFROM:+0200
TZOFFSETTO:+0100
END:STANDARD
BEGIN:DAYLIGHT
DTSTART:20200329T020000
RRULE:FREQ=YEARLY;BYDAY=-1SU;BYMONTH=3
TZNAME:CEST
TZOFFSETFROM:+0100
TZOFFSETTO:+0200
END:DAYLIGHT
END:VTIMEZONE

Sweden changes from CEST to CET on the 30th of October which is the 5th Sunday, not the 4th.

Is this an issue with iCal.NET or something else?

Kind Regards

@eriknuds
Copy link

eriknuds commented Oct 27, 2021

We experience the same here. It's the same for most/all western standard time zones I think.
It happens because of this bug which has been reported before and is not yet fixed...(#444):
`

    private class IntervalRecurrencePattern : RecurrencePattern
    {
        public IntervalRecurrencePattern(ZoneInterval interval)
        {
            Frequency = FrequencyType.Yearly;
            ByMonth.Add(interval.IsoLocalStart.Month);

            var date = interval.IsoLocalStart.ToDateTimeUnspecified();
            var weekday = date.DayOfWeek;
            var num = DateUtil.WeekOfMonth(date);

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


    public static int WeekOfMonth(DateTime d)
    {
        var isExact = d.Day % 7 == 0;
        var offset = isExact
            ? 0
            : 1;
        return (int) Math.Floor(d.Day / 7.0) + offset;
    }

`

The datetime used here is "DTSTART:20191027T030000". Nodatime (probably correctly) reports it as the datetime of change according to the most recent adjustment rule.

That was the 4'th sunday that year (also the last). But this year there are 5 sundays in october. And the correct rule would be the last, not the 4th sunday. But since the old 2019 date for last sunday is used, and that was in week 4 of the month, the WeekOfMonth() returns 4 and not 5 witch would be correct for this year...and thus the rule becomes 4th sunday, not last sunday...

It is an error to assume that the datetime of the most recent adjustment rule for dst/std will be in the same week of the month for all years. It is not. And then the calculation will be off by an hour in this case. Which is very bad.

This has really caused us some grief now...
The bug will only manifest itself for dates between the 4th and 5th sunday of october.

@chiarapivetta
Copy link

I'm having the same problem setting "Europe/Rome" and "CET" as TimezoneId. The rule should definitely be the last Sunday of March/October. Is there any chance this will be fixed soon?

@gonace
Copy link
Contributor Author

gonace commented Oct 23, 2022

@rianjs is this something that could be solved? When looking at the current state of pull requests they seem not to be merged (the last merged pull request is Apr 10, 2021) so for us to fix this bug, then have to wait a few months or years is sadly not an option.

@gonace
Copy link
Contributor Author

gonace commented Jan 20, 2024

@chiarapivetta @eriknuds 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.

@axunonb axunonb closed this as completed Oct 13, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

4 participants