Fix ZDT diff issue with ymd travel with opposite sign of ns travel

[arshaw]

Fix for #3311

Just some strategically placed short-circuits guarding against weird scenarios, falling back to time-only math.

Output:

const zdt1 = Temporal.ZonedDateTime.from('1867-10-18T12:44:35.000000001-11:47[America/Adak]');
const zdt2 = Temporal.ZonedDateTime.from('1867-10-19T00:00:00+12:13[America/Adak]');
const realDuration = zdt1.since(zdt2); // PT12H44M35.000000001S

zdt1.since(zdt2, { largestUnit: 'days' }); // PT12H44M35.000000001S
zdt2.until(zdt1, { largestUnit: 'days' }); // PT12H44M35.000000001S
realDuration.round({ largestUnit: 'days', relativeTo: zdt2 }); // PT12H44M35.000000001S
realDuration.total({ unit: 'days', relativeTo: zdt2 }); // 0.26548032407407984

// from ptomato's follow-up investigation
realDuration.round({ largestUnit: 'days', relativeTo: zdt1 }); // PT12H44M35.000000001S
realDuration.total({ unit: 'days', relativeTo: zdt1 }); // 0.5309606481481597

All results look reasonable, except for maybe the first .total one. Gotta think through if that's correct. Might be related to another PR I'm about to make...

[codecov]

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 98.39%. Comparing base (4df4199) to head (c609e43).

Additional details and impacted files

@@           Coverage Diff           @@
##             main    #3317   +/-   ##
=======================================
  Coverage   98.39%   98.39%           
=======================================
  Files          22       22           
  Lines       10763    10775   +12     
  Branches     1866     1868    +2     
=======================================
+ Hits        10590    10602   +12     
  Misses        161      161           
  Partials       12       12           

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.
• 📦 JS Bundle Analysis: Save yourself from yourself by tracking and limiting bundle sizes in JS merges.

[ptomato]

And another big thank you for looking into this one as well!

I haven't yet had a chance to dig as deep into this issue as I have into the other ones, so I'll have less to say.

Firefox's proposed patch also had something similar to the first part of yours, falling back to time math if isoDtStart/isoDtEnd passed each other. (They had a second fix in ZonedDateTime.round which I didn't believe was correct though.)

This PR passes the tentative test262 tests I've written, but note that I still need to validate those against the ideas that Justin wrote down in #3311 (comment).

I threw a bunch of snapshot tests at this PR and noticed that it does change one result that I wasn't expecting:

const earlier = Temporal.ZonedDateTime.from('2011-12-29T23:59:59.999999999-10:00[Pacific/Apia]');
const later = Temporal.ZonedDateTime.from('2011-12-31T00:00+14:00[Pacific/Apia]');
earlier.since(later, { largestUnit: 'days' })
  // was    : P1DT0.000000001S
  // becomes: PT0.000000001S

This is indeed falling back to time math, but here I'm not sure that it should, since it's a +24h transition where the direction of travel of wall clock and exact time is the same.

[ptomato]

These two conditions can probably collapse into if (CompareISODate(isoDtStart.isoDate, isoDtEnd.isoDate) === -sign)?