is there any support for correcting time shift over dst/std change?

[sdetweil]

rule start in dst (germany, 10/3 is DST), cycle takes to event instance in std time, (event is 10/6, STD) date right, time wrong (using dst time from start object).

this the second combiner problem, including #420

right now I compare if the offsets of the two dates are different (really TODAY, as we are running the rule, and the rule instance date)

and adjust the resultant time by 1 hour in either direction.

[aldeng11]

I'm having this same issue, and it's gotten critical as all our meetings have gone to Zoom. Here in the US, we don't change our clocks at the same time as Europe and I don't see how to write an RRULE that will shift the time based on a European time zone in mid-sequence.

A workaround would be to give me a render callback (the built-in one from fullcalendar doesn't let me edit the date) on each instance where I could evaluate the date against the local time zone and apply the correct offset.

[torgeadelin]

When you schedule a meeting repeating every day from 25 to 31st of March at 9am UK (GMT), assuming time changes on the 28th to BST, is there a way of correcting the .toAll() method that returns all date instances of the recurrence? I would assume it should return something like this

[
  "25 March 9am in UTC" ,
  "26 March 9am in UTC" ,
  "27 March 9am in UTC" ,
  // switch back an hour so that the initial time is still 9am
  "28 March 8am in UTC" ,
  "29 March 8am in UTC" ,
  "30 March 8am in UTC" ,
  ...
]

Anybody solved this issue? It's unclear in the docs if this library takes into account DST changes when expanding the rrule.

[sdetweil]

i have had to implement tz/daylight savings correction up in my app... also our date.time is in UTC and man does that cause a problem with luxon,..

[torgeadelin]

Hi @sdetweil, why do you have issues with luxon and UTC?

Also, how did you approach the problem?

[sdetweil]

luxon assumes the date is LOCAL time..

20210323T230000z when u are in germany is 20210324T010000 luxon uses 0323

so, before calling rule.between i have to adjust the rule start to be 0324... (otherwise the day of the week could be off.. and results get nutty)

so if the time of the start is within the timezone utc offset (either specified or current), I have to adjust the start to be a day later

then after I get the list, have have to check if the offset of the start is different than the offset of the date in the list and if so correct the time in the date from the list..

I just fixed a problem where the start time was april 4 1952, and daylight hadn't started yet... but it would have now.. so i have to change the year to after 2007 (last daylight start adjustment change in the US)

its a pain in the rear when all the components don't agree on the notation...

a bunch of our users are using this for zoom meetings across timezones (and ds/std time adjustments...).

[cbaec]

We have the same problem here. Are you working on a fix in the package?

[sdetweil]

sadly, I don't see a 'fix' for RRULE, as it says

Important: Use UTC dates
Dates in JavaScript are tricky. RRule tries to support as much flexibility as possible without adding any large required 3rd party dependencies, but that means we also have some special rules.

By default, RRule deals in ["floating" times or UTC timezones](https://tools.ietf.org/html/rfc5545#section-3.2.19). If you want results in a specific timezone, RRule also provides [timezone support](https://www.npmjs.com/package/rrule#timezone-support). Either way, JavaScript's built-in "timezone" offset tends to just get in the way, so this library simply doesn't use it at all. All times are returned with zero offset, as though it didn't exist in JavaScript.

The bottom line is the returned "UTC" dates are always meant to be interpreted as dates in your local timezone. This may mean you have to do additional conversion to get the "correct" local time with offset applied.

[wardds]

From my own trial and error and reading the open issues it seems there is indeed no way to express an event happening every day at 10am in Europe/Paris and have it work across the DST change.

I may attempt to store the original timezone offset in the configuration and then compare each generated entry and apply whatever difference there is between the stored offset and the offset at that generated time of the IANA timezone. Or find a new library altogether, although the pickings are slim. Actually this will require also adjusting the times of .between() calls so rrule can generate the right occurrences at all, which then still need plenty of conversion logic.

Either way the library does solve many other parts of the equation to have users schedule events, but there's lots of caveats to still work around.