Re: [calsify] RFC 5545/JSCalendar questions from ECMAScript TC39 "Temporal" working group

[Neil Jenkins <[e-mail]>]

On Fri, 31 Jul 2020, at 05:10, Justin Grant wrote:
> Hi JSCalendar team – I’m part of the TC39 working group that’s working on the Temporal <https://github.com/tc39/proposal-temporal> proposal which will be the future date/time API for JavaScript.  We’re planning to follow RFC 5545 for operations that add or subtract durations from date/time values.  But we have some questions about how to interpret the iCalendar spec around edge cases when there’s a DST transition during the added or subtracted duration.

> […]
> P.S. – Apologies for contacting you individually via email instead of via the public mailing list. I tried to join that list but never heard back, so I’m falling back to old-school individual emails.


Hi Justin,

I'm happy to answer some questions; your link was to the GitHub project rather than a specific issue, but I'm presuming it's https://github.com/tc39/proposal-temporal/issues/702 that you were referring to.

I've copied this to the calsify (Calext WG) list <https://www.ietf.org/mailman/listinfo/calsify>, but encourage people to reply-all as you have had difficulty joining it.

In answer to the questions in that issue, my understanding is:

Q1. As specified in RFC5545 (and JSCalendar):
 * A duration does not have a time zone associated with it. It is just an abstract number of weeks/days/hours etc.
 * If you want to determine how long in absolute terms a duration with days/weeks is, this question only makes sense when you have a start date-time to apply it to.
 * A duration may be added or subtracted from a date-time. If the date-time does not have an associated time zone then this is very easy (it's just like UTC: 1 day is always exactly 24h).
 * Otherwise, as per the spec, you would add the weeks/days first to the calendar day/month/year. If the result is an ambiguous time due to DST, you resolve at this point. Then you add the absolute hours/minutes/seconds etc. – this cannot result in another ambiguity. There is only ambiguity mapping from TZ -> UTC, not UTC -> TZ.

I think your implementation in (1) seems similar to this, but I have not looked at the source closely to confirm. I'm not sure why you think the disambiguation in the middle is going to be problematic for users; surely they generally won't notice where it happens? You just add the duration to the date-time and get a result.

If I'm understanding it correctly, I do not think your proposed alternative is acceptable because it applies the time component to the wall-clock time, which means that if you had an event with duration PT1H that started on a 1-hour DST-transition point it would be translated into an absolute duration of 0 hours or 2 hours, which is clearly wrong! e.g. I have an event that starts at 2019-03-31T02:45 in Europe/Berlin. I add a duration of PT1H in wall clock time to get 2019-03-31T03:45 in Europe/Berlin. However, those are the same time in UTC due to the DST transition, so the absolute duration becomes 0!

Q2. I don't think this issue arises when following the RFC5545 semantics above.

Q3. I don't think subtraction is well specified and probably wasn't deeply considered; it is basically only used for the offset of alerts before the start of the event and I think your proposal of subtracting absolute components first is very reasonable for the reason you gave. We should clarify this in the JSCalendar spec.

Q4. This is really an implementation question. The result is clearly only correct if you can add it to the start date and get back the end date again with the already defined semantics. You can either:
 * Just find the difference in absolute time and represent this as a duration in hours/minutes/seconds.
 * Subtract hours/minutes first to get the same wall clock time, then calculate number of days difference to get a duration in weeks/days/hours/minutes/seconds.

Q5. I don't think I quite understand your question. You say you are "calculating differences between UTC values" but then the "difference ends inside a DST discontinuity" – UTC doesn't have DST, so this doesn't make sense. Could you please clarify?

Cheers,
Neil.