Issue Summary

In specific scenarios, Team Calendars ignores timezone of the event or the calendar for subscribed calendar and display the recurring event in wrong day.

Sample iCal file: google_calendar.ics
In the 'Steps to Reproduce' section, I will share the steps to create a Google Calendar to replicate the same. This .ics file is downloaded version of the calendar that I created using the same steps in the Google Calendar.

There are timezone definitions for start and end periods in events:

DTSTART;TZID=Europe/London:20240102T170000
DTEND;TZID=Europe/London:20240102T173000

If the VTIMEZONE definition starts with a different timezone and this timezone has big difference with the event's timezone, the event is displayed in the wrong day.

BEGIN:VTIMEZONE
TZID:Asia/Shanghai

In this example;

• the event timezone is Europe/London (and this timezone is included in the VTIMEZONE definitions but not as first)
• the timezone definitions starts with Asia/Shanghai

Also, there is 'X-WR-TIMEZONE' for calendars from Google Calendar which defines the calendar timezone. In this example it is set to UTC:

X-WR-TIMEZONE:UTC

This is reproducible on Data Center: (yes)

Steps to Reproduce

1. Create a new calendar in Google Calendar
2. Create the one event using the below details:
   • Create from January 2024
   • Recurring rule: first Tuesday of month
   • Add time (not all day event)
   • Timezone: Europe/London
3. Create the second event using the below details:
   • Create from January 2024
   • Recurring rule: Third Wednesday of month
   • Add time (not all day event)
   • Timezone: Asia/Shanghai
4. Make the calendar public by navigating its settings
5. Copy the iCal URL
6. Import the calendar to Team Calendar using 'Subscribe by URL'

Expected Results

The first event created with 'Europe/London' will be displayed on first Tuesday of the month.

Actual Results

The first event created with 'Europe/London' is displayed on Mondays.

User profile timezone set to Europe/London:

Workaround

Currently there is no known workaround for this behavior. A workaround will be added here when available