TimeZone.getAbsoluteFor() should be able to match other libraries' disambiguation behaviour?

[ptomato]

Follow up from #316. In TimeZone.getAbsoluteFor(), the disambiguation options are earlier, later, and reject.

@ptomato (from the reference docs) >

The built-in behaviour of the Moment Timezone and Luxon libraries is to give the same result as earlier when turning the clock back, and later when setting the clock forward.

@gibson042 >

This seems to indicate a gap in the Temporal API that should be corrected, and closely relates to Preserving local time (cc @pdunkel).

Indeed it would seem if one would try to reimplement one of these libraries using Temporal, it would be difficult to match their disambiguation behaviour. Are there use-cases that users of these libraries expect this behaviour for?

[justingrant]

(merging content from #614)

It's not just moment/luxon. They inherited this behavior from legacy Date which has the same behavior, thanks to this section in the spec:

When tlocal represents local time repeating multiple times at a negative time zone transition (e.g. when the daylight saving time ends or the time zone adjustment is decreased due to a time zone rule change) or skipped local time at a positive time zone transitions (e.g. when the daylight saving time starts or the time zone adjustment is increased due to a time zone rule change), tlocal must be interpreted with the time zone adjustment before the transition.

In addition (or instead?), we may want a disambiguation: 'compatible' option for inTimeZone/getAbsoluteFor. I don't have a strong opinion, but mildly prefer having a compatible option because it's more discoverable than a TimeZone method (esp. inside IDEs where it'll show up inside the autocomplete UI) so might prevent bug reports about compatibility.

During the TC39 stages, discoverability also might help to highlight the incompatibility to more developers in case there's some important reason we don't know about why the current legacy Date behavior is actually helpful instead of being an arbitrary legacy decision. (Although my bet is on latter.)

[justingrant]

Could we re-open this discussion?

I now have a stronger opinion about this, because I learned that RFC 5545 (and other calendar standards like JSCalendar) also requires the same behavior as legacy Date. Here's what RFC 5545 says:

      If, based on the definition of the referenced time zone, the local
      time described occurs more than once (when changing from daylight
      to standard time), the DATE-TIME value refers to the first
      occurrence of the referenced time.  Thus, TZID=America/
      New_York:20071104T013000 indicates November 4, 2007 at 1:30 A.M.
      EDT (UTC-04:00).  If the local time described does not occur (when
      changing from standard to daylight time), the DATE-TIME value is
      interpreted using the UTC offset before the gap in local times.
      Thus, TZID=America/New_York:20070311T023000 indicates March 11,
      2007 at 3:30 A.M. EDT (UTC-04:00), one hour after 1:30 A.M. EST
      (UTC-05:00).

Developers can roll their own disambiguation behavior per the cookbook example above, but there does seem to be a cross-platform standardized behavior and legacy behavior that Temporal is diverging from, so for interop reasons it seems worthwhile to make it easier to get the compatible behavior.

Whether to make this the default behavior is also worth discussing, but providing an easy-to-use option to support popular interop use cases seems like a good idea regardless of the default.

[ptomato]

Meeting, June 18: No problem adding this behaviour and making it the default, since it is the default in many other places, as long as the option to choose the behaviour remains.