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

[Neil Jenkins <[e-mail]>]

On Sun, 2 Aug 2020, at 13:04, Justin Grant wrote: 
> > Q1. [...] 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? 
> 
> Here's an example: what should be the result of adding P1DT12H to 2020-03-07T02:30-08:00[America/Los_Angeles]. My understanding of RFC5545's algorithm is that we'd use the following steps:
>   A) Add 1 calendar day.
>   B) Add 12 exact hours (not clock hours)
> But the after step A, the local time is not valid because 2020-03-08T02:30 is in the middle of the hour skipped by a DST transition. My interpretation of RFC 5545 is that we'd interpret the invalid intermediate time by using the offset before the transition, so we'd end up with an intermediate value of 2020-03-08T03:30-07:00[America/Los_Angeles] and a final result of 2020-03-08T15:30-07:00[America/Los_Angeles].  Is this correct?

Yes, that's my understanding too.

> Are both of these compliant with your understanding of RFC 5545?  Is only one correct?  Or is neither correct?
> 
> 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).

OK, so I think I see the cause of the confusion. They are both correct(!) BUT this is because there is a subtle difference between the Temporal *LocalDateTime* and RFC5545 *Date with local time and time zone reference*. The latter does not have a UTC reference point; it's just a wall clock time.

You can add either P1D or P1DT1H to 2020-10-31T01:30 and get a wall clock time of 2020-11-01T01:30. Both are correct durations to calculate as the difference between X and Y, because Y could be two different absolute times (the -08:00 is not encoded in the RFC5545 model).

Due to conversion rules, when converting to UTC you always interpret 2020-11-01T01:30[America/Los_Angeles] as -07:00, not -08:00, should you need an absolute time. If you want to reference the other point in time specifically you would need to use UTC (or I guess any time zone where it is unambiguous).

Note, in general the lack of offset encoded with the time zone is a feature not a bug; otherwise you end up with nonsensical data should the time zone definitions change (what would you do with 2020-11-01T01:30-08:00[America/Los_Angeles] should California suddenly decide to join the One Glorious US Average Time Zone of -06:30?!). If the offset is fixed, you need to use UTC (or a fixed offset zone like Etc/GMT+8), not a real time zone.

> Another problem is that the logic above can deliver unexpected results depending on the local time of the endpoints, even if neither of those endpoints are close to a DST transition.  For example, using the "Addition Path" logic above, here's the durations that the following pairs of LocalDateTime values will return: 
>  * 2020-03-07T01:30-08:00[America/Los_Angeles] to 2020-03-08T13:30-07:00[America/Los_Angeles] => P1D12H

I think this one is incorrect. Following your Addition Path algorithm:

  A) Let D = Y - X => 1 day 12 hours
  B) Truncate the time portion of D => 1 day
  C) Let I = X+D => 2020-03-08T01:30[America/Los_Angeles] => 2020-03-08T09:30:00Z
  D) Y = 2020-03-08T20:30:00Z; I - Y => 11H
  E) Merge N and T: P1DT11H

>  * 2020-03-07T02:30-08:00[America/Los_Angeles] to 2020-03-08T14:30-07:00[America/Los_Angeles] => P1D11H (1 hour less because the intermediate time 2020-03-08T02:30 is resolved to 2020-03-08T03:30-07:00[America/Los_Angeles] before the exact time difference is calculated)
>  * 2020-03-07T03:30-08:00[America/Los_Angeles] to 2020-03-08T15:30-07:00[America/Los_Angeles] => P1D12H
> 
> Users probably won't be surprised to see divergent results in cases where the endpoints are within an hour of a DST transition. But what's unexpected is the variation in results caused by the intermediate result landing on an invalid time, even though neither of the endpoints are very close to the transition.
> 
> Does this clarify the problems we're trying to resolve with Q5?

I think I see. So the issue you have is if the end day is a daylight savings transition *day* and the start time is prior to the daylight savings transition *time*, then you have the intermediate adjustment which may be surprising to users. Firstly, this is actually going to be very rare that you hit it (so the likelihood of someone coming across it and actually *being *surprised is minimal, and the issue is the surprise, not necessarily the semantics); secondly, I think you would have to change the interpretation of durations (Q1) in order to do anything different, which seems a breaking change for minimal gain in my view.

Neil.