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

[Neil Jenkins <[e-mail]>]

On Mon, 3 Aug 2020, at 14:46, Justin Grant wrote:
> Yep, agreed. This is a rare use case so it's definitely not worth a breaking change. Our goal is to find a deterministic, least-surprising solution for this weird case.  Ideally someone else would have already standardized how to handle this case and we could just adopt the standard, but so far I haven't found it.
> 
> Does JSCalendar include any guidance about how to calculate durations from two date/time+timezone (DATE-TIME - FORM #3) values?  If not, would you be interested in collaborating with us to define an algorithm that could be used by Temporal and included in the JSCalendar spec? This may help with interop.

We don't have anything currently defined, but I am interested in adding it; I agree it could be useful for interop.

> Finally, could you explain what you mean by "*I think you would have to change the interpretation of durations (Q1) in order to do anything different"* ?

What I mean is that the addition operation of a duration to a date is well defined, and we don't plan to change it. Therefore, the “correctness” of an algorithm for calculating a duration between dates X and Y is constrained by the simple fact that the duration "D" that results must be such that X + D = Y.

The Temporal case is further constrained because you are representing both sets of dates in overlapping time periods. Therefore to go back to the example you gave in the previous email:

> One problem is that the Addition Path and the Subtraction Path can return different results when an endpoint is in the "repeated hour" after DST ends in the fall. For example, assume that X is 2020-10-31T01:30-07:00[America/Los_Angeles] and Y is 2020-11-01T01:30-08:00[America/Los_Angeles] (the "second" 1:30AM on the day DST ends).  If we start from X, then we'd add one nominal day to get 2020-11-01T01:30-07:00[America/Los_Angeles] (the "first" 1:30AM), and then add one exact hour to get to the end. So the result is P1DT1H.  But if we start from Y, then subtracting one nominal day from 2020-11-01T01:30-08:00[America/Los_Angeles] yields 2020-10-31T01:30-07:00[America/Los_Angeles]. There is no time remainder. So the result is P1D.

As I said before, both of these durations are arguably valid in RFC5545. However in Temporal, the Subtraction one is not valid:
 * X = 2020-10-31T01:30-07:00[America/Los_Angeles]
 * Y = 2020-11-01T01:30-08:00[America/Los_Angeles]
 * D = P1D (by the subtraction method)
 * X + D = 2020-11-01T01:30-07:00[America/Los_Angeles] ≠ Y

The "Addition" algorithm however does produce the correct result, and I think is a reasonable basis for an algorithm to adopt. The one change I think it needs is to account for when the time of the earlier date is in the no-mans-land of a DST transition, and the end day is on a transition day. e.g. 
 * X = 2020-03-06T02:30-08:00[America/Los_Angeles]
 * Y = 2020-03-08T03:15-07:00[America/Los_Angeles]
If you try to use the Addition Path:
 * Let D = Y - X ignoring TZ => P2D
 * Let I = X+D => 2020-03-08T02:30 => 2020-03-08T03:30-07:00[America/Los_Angeles] according to resolution rules, which is after Y.
So I think that we just need to add an extra check at step (C): if you get an absolute time *after* the end time Y, subtract 1 day from the duration and try again. e.g.
 * Let D = P2D - 1 day => P1D
 * Let I = X+D => 2020-03-07T02:30-08:00[America/Los_Angeles]
 * Let T = Y - X in absolute time => PT23H45M
 * Result = D + T => P1DT23H45M

Neil.