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

[Justin Grant <[e-mail]>]

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.
>
>