[calsify] Subtraction vs. DST disambiguation

[Justin Grant <[e-mail]>]

Hi Neil (and others!) -

This email is a follow-up to our previous discussions about how Temporal
and JSCalendar should specify the subtraction algorithm. We previously
agreed that, in order to make subtraction reversible with subsequent
addition of the same value, we'd reverse the order of operations so with
subtraction of a positive duration (or adding a negative duration) the time
portion would be subtracted first, and then the date portion.

I think I found another potential problem with subtraction: DST
disambiguation of nominal times that end up in the middle of a DST-skipped
period. The default behavior is to use the earlier offset, which results in
one hour later than the invalid time. This makes the clock time impact of
the addition operation one hour longer.

But what if you're subtracting days and the endpoint of the subtraction is
in the middle of a skipped period?  In that case, clock time is still
advanced one hour, which makes the subtraction result one hour shorter.

For example: `2020-03-09T02:30-07:00[America/Los_Angeles]` -` P1D`
The result is `2020-03-08T03:30-07:00[America/Los_Angeles]`
And if I add `P1D` to that result, I get
`2020-03-09T03:30-07:00[America/Los_Angeles]`, which is one hour later than
my original time.  It's not reversible.

I'm not sure there's any way to avoid this problem. We could choose to
reverse the disambiguation behavior and pick the later offset, but that
doesn't solve the reversibility problem, because we'd just get a
one-hour-earlier result instead of a one-hour-later one. It'd also
introduce interesting behavior where the same result in nominal time is
resolved to a different result in exact time depending on whether a
subtraction or an addition was being performed.

There's also another, more obscure problem: in rare cases time zone
discontinuities can be a full day long, e.g. Samoa's 2011 switch to
opposite sides of the International Date Line where `2011-12-30` was
skipped. In that case, I could get into an infinite loop while subtracting
`P1D` from `2011-12-31T12:00+14:00[Pacific/Apia]` because after subtracting
one day in nominal time, we'd add that one day right back to end up with
the same result:  noon on Dec 31.

Note that this is only an issue when subtracting full days, because
subtracting times will always use exact time.

Anyone have any ideas for how we should handle this case?  Should we use
the later offset for disambiguation when subtracting full days, but use the
earlier offset for disambiguation in all other cases?  Or is there some
other, more-targeted solution?  Or is the weirdness with the date-line
change rare enough that we shouldn't worry about it?

Cheers,
Justin Grant
https://github.com/tc39/proposal-temporal