Recurring events created in DST are off by an hour after DST

[lagnat]

I'll start by saying that this feels like a bug but maybe it's user error?

I have an event with this date (12:10PM)
DTSTART;TZID=America/New_York:20190922T121000

Becomes 11:10AM when filtering events with event.rrule.between() on 3-Nov.

[prapicault]

I'm experiencing the same problem.

[skylerknight]

Also experiencing this. Anyone find a solution yet?

[sdetweil]

i had to add code to my app to check and adjust the time if the offsets change between now() and the target event time
also had to fix rule wrong date with right time for timezones east of London..

[niklasdahlheimer]

I'm experiencing the same problem and have done some research.

ical is parsing all dates as UTC which is great for most cases except recurring events in DST timezones.

The problem is, that RRULE needs to have a DTSTART with timezone included to "know" that start times should shift in DST periods. See ical specification:

In most cases, a "DTSTART" property of DATE-TIME value type used with a recurrence rule, should be specified as a date with local time and time zone reference to make sure all the recurrence instances start at the same local time regardless of time zone changes.

Here the timezone information of start date is ignored while parsing the rrule:

ical.js/node-ical.js

Line 34 in 1308804

rule += ';DTSTART=' + curr.start.toISOString().replace(/[-:]/g, '');

(you can see also the UTC parsing because toISOString() always returns UTC time only)

So the created rrule has no info about timezone and/or DST and can not handle the hour-shift.
I've tried to attach tzid to the rrule later (before creating the recurring events according to the example) but this makes no difference because rrule seems to need the tz info inside dtstart.

Right now I have also no idea how to solve this issue without manual manipulation of the recurring events afterwards (but therefore we would need to hardcode the timezone or parse dtstart of events again on our own..)

I've created a sandbox to play around with this issue
https://codesandbox.io/s/ical-test-recurring-events-8sb40f?file=/src/index.js:670-690

[sdetweil]

yes, its a mess.. i've had to add a ton of code to the calendar handler in MagicMirror to try to make some sense of it all.

nobody has the complete picture and makes a mess at the app level. isoString and DST just add to the mess (did you know there are 5 different DST start/end times.. SO, you get a recurring that was scheduled in the old NON DST adjust , which IS a DST adjust now and the hour is wrong.... so much fun!)

see the code in MagicMirror, all after node-ical has parsed the ics data
https://raw.githubusercontent.com/MichMich/MagicMirror/master/modules/default/calendar/calendarutils.js

starts with
filterEvents which calls calculateTimezoneAdjustment

I've just worked out another issue with recurrences (one of the repeating events is moved out of the schedule) which bombed east of UTC because of toISOString() again.

[niklasdahlheimer]

After this issue mentioned that the node-ical fork eventually solved the problem, I spend some more hours trying to get the fork working... what was again leading to more confusion than before.
Frustrated by all the time I spend in this topic, I gave Mozillas ical.js a shoot and ...booom... it took me about 2 hours to set up the parsing and it works flawlessly ... I didn't find any unexpected or hard-to-fix behavior yet, all well documentated and presumable. Recurring events with/without DST are parsed as expected.
I used a few lines from this repo

If anyone else gets stucked with the issue described here, I can encourage you to give Mozialls ical.js a shoot (my apologies to the repo owners here!)

[jamesdoc]

FYI: The issue I mentioned said that it might solve the issue. TBC

[niklasdahlheimer]

FYI: The issue I mentioned said that it might solve the issue. TBC

sorry, that was a translation mistake, I meant "might", not "eventually" (which, directly translated to German, means "might" :D ).

But bottom line: In my experience the fork does not solve this issue.