1

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.

Justin Grant
  • 44,807
  • 15
  • 124
  • 208

2 Answers2

2

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:

Community
  • 1
  • 1
anmari
  • 3,830
  • 1
  • 15
  • 15
  • Thanks, this was exactly the info I was looking for. To summarize: it sounds like RFC 5545 considers time units to be "exact time" but considers date units to be "nominal dates". So P1DT12H means "one calendar day and 12 real-world hours". Thanks for your help and clarifications! – Justin Grant Jun 03 '20 at 00:01
  • Great explanation, although I don't fully agree, that what the RFC specifies is always intuitive. E.g. I want to specify an event that repeats every day 'off-office-hours', e.g. every day from 20:00 until 8:00. If there's a DST change during a recurrence interval, the interval should still end at 8:00. To my understanding this cannot be modeled using a single RRULE (although this is a slightly different question than whether it's intuitive). Correct? (also see https://stackoverflow.com/questions/74566867/does-rfc-5545-allow-specifying-a-nominal-duration-shorter-than-24h) – MarkusM Jan 09 '23 at 17:33
0

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.

Community
  • 1
  • 1
anmari
  • 3,830
  • 1
  • 15
  • 15
  • Yep, the event time must be UTC for exactly the reasons you noted. I'm specificity asking about duration behavior. – Justin Grant May 31 '20 at 04:44
  • The spec refers to calculating the exact duration, not applying or 'acting' upon it. So if say an event began at 1.10am local time ( first instance) and ended at 2am at DST cutover, one must add the 60 minutes - the exact duration will be 110 min. If referring to the second 1.10am, one would have to use UTC time to specify that second 1.10am and thus when calculating the exact duration one would calculate 50 minutes to 2am. In your reminder example if starting at 1.10 am (2nd instance, specified in UTC) , then a 15 minute reminder would take us to 1.55am (first instance). – anmari May 31 '20 at 05:04
  • Google Calendar handles this amusingly and confusingly. If I create a event starting at 1.15 on 4 October (our DST change) and choose 2.15 am (1 hr ) as endtime, on saving, it forces and displays a 2 hour block (which is correct in realtime), but confusing as it shows 3.15 as the end time (which is not correct ;) ) – anmari May 31 '20 at 05:13
  • In google calendar one can choose to 'separate' start end timezones, choose a GMT+11 TZ for the end time (where start is Sydney at GMT+10), choose an end time that equates to one hour, save. The calendar view then shows start at 1.15 and end at 1.15 and shows a one hour block. In summary, your reminder of 15 Minutes should be realtime 15 minutes, not 75 minutes. Anyone calculating the reminder time then has to represent that time correctly, using UTC if necessary. – anmari May 31 '20 at 05:29
  • The core of my question is: "What does the string form of RFC 5545 durations actually mean? Does it mean a real-world stopwatch time, aka 'exact time'? Or does it mean a clock time delta (aka 'nominal time') whose actual real-world stopwatch length will vary if the duration crosses a DST transition?" Do you know the answer? – Justin Grant May 31 '20 at 19:38
  • It means real world stopwatch time/exact time. See the examples: https://icalendar.org/iCalendar-RFC-5545/3-3-6-duration.html and https://icalendar.org/iCalendar-RFC-5545/3-8-2-5-duration.html – anmari Jun 01 '20 at 06:08
  • So the clearest indication I see in the spec is this: _The format can represent nominal durations (weeks and days) and accurate durations (hours, minutes, and seconds)_. Does that mean that hours/minutes/seconds in durations are treated as stopwatch time, while days and weeks are treated as nominal days? For example, does `P1DT12H` mean "one calendar day and 12 real-world hours" or "one calendar day and 12 clock hours" or "36 real-world hours" ? – Justin Grant Jun 02 '20 at 00:34
  • The length of a nominal day, month or year depends on its place in the calendar. EG: a nominal day could be 24 or 23 hours, a nominal month could be 28,29,30 or 31 days, a nominal year could be 365 or 366 days. Thus P1DT12H is not (always) the same as PT36H. If a duration of exactly 36 Hours is required, then we should use PT36H. If it is intended that an event end at the same 'o'clock' time plus 12 hours even if daylight saving occurred, then we should use P1DT12H. – anmari Jun 02 '20 at 06:25
  • I tried to find more worked examples to help us with this. Not many out there. EG: https://github.com/moment/moment/issues/4815#issuecomment-430787067 has discussion: "For hours, "PT36H" should not be parsed as 1 day and 12 hours, but as 36 hours, because daylight saving changes can occur." – anmari Jun 02 '20 at 06:27
  • More: https://stackoverflow.com/questions/26265751/what-is-the-value-of-the-iso-8601-duration-p1m-in-seconds "If you want a fixed duration indepedent of the context, use the day notation P30D, P60D, P90D... instead." – anmari Jun 02 '20 at 06:29