Is there any RFC standard that defines which timezone wins for recurring events if daylight savings occur?

Question

Example

• An Austrian who works in Vienna has a video call on October 28th, 2022 with an Indian who works in New Delhi (note that in Austria it is still daylight saving time on October 29th, 2022, but it ends at October 30th, 2022). The time is:
  • in UTC at 12:00 (Coordinated Universal Time, UTC +0)
  • in Austria at 14:00 (Central European Summer Time, UTC +2)
  • in India at 17:30 (India Standard Time, UTC +5:30)
• They agree to meet for the next 2 days (October 29th, October 30th) at the same time.
• But because of DST on October 30th, 2022 the same time is:
  • in UTC at 12:00 (Coordinated Universal Time, UTC +0)
  • in Austria at 13:00 (Central European Time, UTC +1) <-- Note that the timezone and the UTC offset changed
  • in India at 17:30 (India Standard Time, UTC +5:30)

Questions

How does the iCalender file look like if I want the austrian timezone to "win"? And is this even possible according to a RFC standard? If the austrian timezone "wins", then the time changes and the video calls are 1 hour later at October 30th:

• in UTC at 13:00 (Coordinated Universal Time, UTC +0)
• in Austria at 14:00 (Central European Time, UTC +1)
• in India at 18:30 (India Standard Time, UTC +5:30)

Is it enough to simply include the timezone in DTSTART like this? If yes, which RFC defines it?

BEGIN:VCALENDAR
  BEGIN:VEVENT
    DTSTART;TZID=Europe/Vienna:20221029T140000
    RRULE:FREQ=DAILY;COUNT=2
  END:VEVENT
END:VCALENDAR

And if there is a RFC which defines how the iCalendar file must look like, is there also an RFC that defines that every implementation has to calculate the single dates for this iCalendar file at 13:00 UTC, 14:00 in Austria and 18:30 in India as soon as the DST change occurs?

Answer 1

The Time Zone Identifier is defined in section-3.2.19 of RFC5545 .

The example you give is appropriate for TZID in a DTSTART. See the comment in the same section 3.2.19

This parameter [TZID] MUST be specified on the "DTSTART", "DTEND", "DUE", "EXDATE", and "RDATE" properties when either a DATE-TIME or TIME value type is specified and when the value is neither a UTC or a "floating" time [...] following are examples of this property parameter:

DTSTART;TZID=America/New_York:19980119T020000 DTEND;TZID=America/New_York:19980119T030000

It should be noted the standard mandates the definition of the TZID in the same file inside a VTIMEZONE component.

An individual "VTIMEZONE" calendar component MUST be specified for each unique "TZID" parameter value specified in the iCalendar object.

as such implicit references to TZID often work but aren't compliant to the standard.

The standard does not specify that client has to compute the single dates for this iCalendar file at 13:00 UTC, 14:00 in Austria and 18:30 in India as soon as the DST change occurs? rather the client has to compute when the event has to occur as a function of which timezone it is defined in and then compare to local time and see if they match.

The easier way to see it is to say the clients computes the datetime of all events in UTC time taking into account the TZID it is define in and checks current time vs UTC to see if an alarm has to be triggered.