CODEWITHSUNDEEP
icalendarrrulerfc5545
Ogre
Ogre

Reputation: 861

How are nonexistant timestamps due to DST handled in iCalendar Recurrence rules?

I am trying to determine if the Recurrence Rules specified in RFC 5545 are suitable for my use case. I am a bit confused by section 3.3.10. https://datatracker.ietf.org/doc/html/rfc5545#section-3.3.10

There are two paragraphs that I consider to be contradictory:

      Recurrence rules may generate recurrence instances with an invalid
      date (e.g., February 30) or nonexistent local time (e.g., 1:30 AM
      on a day where the local time is moved forward by an hour at 1:00
      AM).  Such recurrence instances MUST be ignored and MUST NOT be
      counted as part of the recurrence set.

and

      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.

And for good measure, the relevant part of Section 3.3.5

      If, based on the definition of the referenced time zone, the local
      time described occurs more than once (when changing from daylight
      to standard time), the DATE-TIME value refers to the first
      occurrence of the referenced time.  Thus, TZID=America/
      New_York:20071104T013000 indicates November 4, 2007 at 1:30 A.M.
      EDT (UTC-04:00).  If the local time described does not occur (when
      changing from standard to daylight time), the DATE-TIME value is
      interpreted using the UTC offset before the gap in local times.
      Thus, TZID=America/New_York:20070311T023000 indicates March 11,
      2007 at 3:30 A.M. EDT (UTC-04:00), one hour after 1:30 A.M. EST
      (UTC-05:00).

So it seems to me that in the first quoted paragraph, timestamps that do not exist are skipped, but in the second paragraph, they are reinterpreted into a timestamp that does exist. Which is the actual specified behaviour?

Upvotes: 2

Views: 197

Answers (1)

Dizzy
Dizzy

Reputation: 596

This boils down to whether it's possible to adjust the invalid date/time of the recurrence instance or not.

One example comes to mind is when a time zone is specified in the iCalendar, we know what the UTC offset is for that time of the event. So when the recurrence instance falls on an invalid time, it can be adjusted to the correct time using the offset from UTC instead. (paragraph 2 is the expected behaviour here).

When the iCalendar does not have a time zone set then there is no UTC offset. Therefore no way to adjust the invalid time. (paragraph 1 is the expected behaviour).

For example:

If I said to you. Create a reminder in your calendar every day at 1:30am. There will be one day in the year in your local time (due to DST) that 1:30am doesn't exist, so what should you do? I haven't told you what to do in this case so you would need to ignore it. If you were to adjust it by an hour that could conflict with another event and it's making an assumption.

If however I said create the reminder everyday for 7:30am BST (UTC+1) you would add it to your calendar in your local time as 1:30am EST (UTC-5), when the day comes and the clocks change for you, 1:30am is invalid. But 7:30am BST is still a valid time and I have given you enough information to work out what it is for your time zone EDT(UTC -4). BST is 1 hour ahead of UTC and EDT is 4 hours behind UTC so we can adjust the time by 5 hours. 7:30am would now become 2:30am for your calendar instead of 1:30am.

Upvotes: 0

Related Questions