DST transitions vs. iCalendar reminders vs. RFC 5545 duration spec

Question

How should an RFC 5545 duration of less than 24 hours act when it crosses a Daylight Saving Time (DST) transition?

For example, assume DST ends at 2:00AM on a particular day, and assume that an event starts at the second 1:10AM on that day. (The first 1:10AM is one real-world hour earlier in Daylight Time, the second 1:10AM is in Standard Time).

If that event has a -PT15M (15 mins before) duration reminder, then how many real-world minutes before the start of the event should that reminder pop up? Should it pop up 15 real-world minutes earlier at the first 1:55AM (in Daylight Time)? Or should it pop up 75 real-world minutes earlier at 12:55AM Daylight Time?

The spec seems to imply the latter behavior, but that behavior seems counter-intuitive to me. If I want a reminder 15 minutes beforehand, I really mean "15 minutes". However it is intuitive for longer reminders, e.g. -P1D should be 25 hours before the start of that event so that you get the reminder at the same local time on the previous day.

Anyway, how do most calendar apps deal with this unintuitive behavior? Do they ignore the spec and always treat reminders <24 hours as exact without adjusting for DST? Or am I understanding the spec incorrectly and it's the -P1D case that will be unintuitive with the one-day reminder showing up at a different local time as the event start time?

Obviously this is somewhat of a corner case because few meetings start in the middle of the night. But there are cases where this could happen, e.g. late-night social events. And if I promise to meet you at the bar in 2 hours, I probably don't mean 1 hours or 3 hours on some nights!

Here's what the RFC 5545 spec says:

In the case of discontinuities in the time scale, such as the change from standard time to daylight time and back, the computation of the exact duration requires the subtraction or addition of the change of duration of the discontinuity.

To clarify further, according to https://standards.calconnect.org/csd/cc-51003.pdf, RFC 5545 has a concept of nominal durations (in local clock time) and exact durations (a real-world stopwatch that ignores DST). The language above is about how a nominal persisted duration should be converted to an exact duration.

This question isn't specific to a particular calendar implementation, but I'm tagging Google Calendar and Outlook here because developers using those APIs probably have the most context about these issues.

Answer 1

Consolidation of answers and comments above and direct answers to questions posed:

First part:

"How should an RFC 5545 duration of less than 24 hours act when it crosses a Daylight Saving Time (DST) transition?"

Answer:

Since the duration is less than 24 hours, the exact number of hours, minutes, or seconds should be used for the duration (realtime). There is no confliction or ambiguity with durations < 24 hours.

Second part:

"If that event has a -PT15M (15 mins before) duration reminder, then how many real-world minutes before the start of the event should that reminder pop up? Should it pop up 15 real-world minutes earlier at the first 1:55AM (in Daylight Time)? Or should it pop up 75 real-world minutes earlier at 12:55AM Daylight Time?"

Answer:

15 real world minutes. The specs clearly say that anything less than one day is exact time. Any confusion or ambiguity around a daylight saving cutoff where a time is 'repeated' is avoided by adhering to the standard for referring a repeated clocktime during daylight savings. IE:

• IE the first instance of a time such as 1.10am is the one that is assumed to be intended when one sees 1.10am for a timezone.
• If one wants to refer to the second instance of 1.10 am one must use another timezone (eg UTC) to clearly identify the actual moment in time.

Third Part:

"how do most calendar apps deal with this unintuitive behavior? Do they ignore the spec and always treat reminders <24 hours as exact without adjusting for DST? Or am I understanding the spec incorrectly and it's the -P1D case that will be unintuitive with the one-day reminder showing up at a different local time as the event start time?"

Answer:

They don't ignore the spec. The specification deals with this as one would intuitively expect. A reminder of < 24 hours (PT24H) is exact. No need to adjust for DST.
Similarly a reminder of 24 hours (PT24H) before should occur exactly 24 hours before.

In the case of a one day (P1D) reminder, a 1 day reminder should occur at the same time the previous day be this 23,24,or 25 hours before. This is as one would intuitively expect. The actual number of hours will of course vary depending on the day's place in the calendar.

P1D is not the same as PT24H, as P1D will depend on the dates place in the calendar, whether DST changeover is happening that day, whereas PT24H is exact.

References:

• Daylight saving time and time zone best practices
• https://www.rfc-editor.org/rfc/rfc5545#section-3.3.5 see DATETIME
• https://icalendar.org/iCalendar-RFC-5545/3-3-6-duration.html
• https://icalendar.org/iCalendar-RFC-5545/3-8-2-5-duration.html

Answer 2

The challenge here is to avoid ambiguity, not just with duration, but also with the event time. See the first point in the summary of answers here Daylight saving time and time zone best practices

To avoid ambiguities and to accurately refer to the 'second' 1.10am one should use UTC timezone for those second instances.

Note: In the DATETIME part of the spec, under Form #3, https://www.rfc-editor.org/rfc/rfc5545#section-3.3.5 it clearly states that a local time with timezone always refers to the first instance.

Page 45 of the above doc says for recurrences it is always interpreted as above (first instance):

If the computed local start time of a recurrence instance does not exist, or occurs more than once, for the specified time zone, the time of the recurrence instance is interpreted in the same manner as an explicit DATE-TIME value describing that date and time, as specified in Section 3.3.5.

I take this to mean that the only way to refer to the second 1.10 am of your example would be using UTC time! (or another timezone not affected by that daylight saving change).

The summary of answers in the stack overflow link above does note that in some cases, one may need to store both local & UTC. I suggest this may be exactly such a situation, where during the repeated cutover hour, the only truly accurate representation of times in that repeated daylight saving hour (the second hour), is the UTC time.