Event Calendar Timezone issue with recurring date

Event calendars & schedulers
1

I have an issue with the Event Calendar component: when I added the timezone property, I have an issue with the recurring date because of the daylight savinf time.

Do you know how to prevent the issue with DST ?

Thanks in advance.
Bao

2

Hi Bao :wave:

Thanks for reaching out and sorry for your trouble.

This is a known issue in case of the recurring events, I just added your voice to the request and you will be notified as soon as there’s a progress with it.

We’re already considering options on how to provide a solution for this, so far the only correct solution we found seems to be to store the time and timezone where the event was created (this is what Google Calendar does and I suppose Outlook does something similar as well), but this complicates things a bit on storage side as well.

Until then it can be solved with separate events for winter and summer time.

Best,
Előd

3

Hello @bao :wave:

Good news: we have shipped Mobiscroll 5.24, where we introduced support for specifying the timezone per event.

While this can be useful for any event, it is crucial when working with recurring events. A common solution when working with events across timezones, is to store the event times in UTC, and display them in any choosen timezone. When a recurring event is stored in UTC, the occurrences are also generated in UTC, then converted to the display timezone. This might be ok sometimes, like automated tasks, but real life events, like a weekly meeting, happens somewhere in a real world timezone, where, in many cases, daylight saving time is observed. In this case, when converting occurrences to the display timezone, the times will be shifted on DST change, which is not what we want (e.g. a weekly meeting should take place at 9AM every week, no matter if DST is on or off). Generating the occurrences on the display timezone is also not correct, since the display timezone might have different DST rules than the timezone where the event is originally scheduled. Storing the timezone on the event makes it unambiguous, and will be correctly converted to the display timezone.

This also helps storing the recurring rules. So far, when a recurring event was created in a specific timezone, but was stored in UTC, beside the times, sometimes the rule also needed conversion, which was complicated (e.g. 11PM EST is 4AM in UTC on the next day, so an event repeating every monday at 11PM should be coverted to repeat every Tuesday at 4AM in UTC).