search

jens-maus / node-ical

NodeJS class for parsing iCalendar/ICS files
Apache License 2.0
116 stars 50 forks source link

Recurring event over daylight savings start/end #97

Open scmunro opened 3 years ago

scmunro commented 3 years ago

I've implemented an example by modifiying example-rrule.js - https://codesandbox.io/s/optimistic-elion-jphq4?file=/src/index.js

In this example, a daily recurring event has been created with the Australia/Sydney TZID just before Daylight Saving Time ends. The next event would appear to be the same time in Sydney but one hour later for UTC. This doesn't appear to be the behaviour.

The issue appears to start at line 81 of the example as the event.rrule seems to be in UTC time without any timezone information (event.rrule.options.tzid is undefined) .

Trying to modify the tzid to provide timezone seems to break things with the following error - Using TZID without Luxon available is unsupported. Returned times are in UTC, not the requested time zone.

A proposed solution to this is reverting to rrule version 2.6.4 (https://github.com/jakubroztocil/rrule/issues/427) but 2.6.6 is required by node-ical.

Any thoughts on how to tackle this issue?

sdetweil commented 3 years ago

there are two problems both in luxon

  1. luxon doesn't know daylight savings
  2. luxon assumes LOCAL time (no tz). node-ical (and others) use utc time, events that start within the timezone utc offset get the wrong date passed to luxon (east and west of UTC both present a problem)..

and daylight date for start and end are a mess in the US at least april 2 in 1952 is NOT yet daylight, but is in 2007, with varying start date/times ... hard to adjust the current event time

scmunro commented 3 years ago

Thanks sdetweil.

I've been able to hack together my own semi-working solution - https://codesandbox.io/s/autumn-shape-5313j?file=/src/index.js .

If a rrule exists you circle back to the data to find the DST information, create an object with dates and adjustment and apply each adjustment where required.

The main issue is that you can get incorrect time adjustments ~24 hours either side of the start/end of DST due to how I've implemented this. I'll circle back to fix it at some point but is not a dealbreaker for me as DST tends to change in the early morning on the weekend meaning most calendar entries fall outside of this window.

If we fix that issue and tidy the code up I think it could serve as a updated rrule example?

sdetweil commented 1 year ago

I've just put in a fix on our app for recurring when the rrule.origOptions.byweekday is specified, the results come back 24 hours off (using the GMT day with the adjusted time) if (curEvent.rrule.origOptions.byweekday !== undefined)