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

[Justin Grant <[e-mail]>]

Hi Neil - reviewing this now. Had a quick question:

> Let T = Y - X in absolute time => PT23H45M

Why is X used here instead of I?  Here's what I would have expected:

Let T = Y - *I* in absolute time  => PT23H45M

On Thu, Aug 6, 2020 at 11:17 PM Justin Grant <
[e-mail]> wrote:

> Hi Neil - Apologies for slow response, I'm on vacation for a few days. At
> first glance your proposal above looks good to me but I'll need to review
> more closely without "vacation brain" when I get back next week.
>
> Cheers,
> Justin
>
>
> On Mon, Aug 3, 2020 at 8:34 PM Neil Jenkins <[e-mail]>
> wrote:
>
>> 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.
>>
>>