Editorial: Remove duplicate steps in UnbalanceDateDurationRelative

[anba]

Some parts of UnbalanceDateDurationRelative could be shared to reduce duplicated steps.

These changes probably shouldn't be applied to the current spec, but instead this PR should be revisited after #2519 and #2612 have both landed. (Maybe mark this PR as a draft PR?)

c4f291f

• Moves the early returns to the top in preparation for the next commits.

74cfd4e

• The early return condition could alternatively be computed algorithmically instead of performing explicit comparisons.
• But I'm not sure if this helps or if it actually just makes it harder to reason about the abstract operation.

76841ba

• The error code path can be moved to the top, too.

a3ae84f

• The GetMethod for "dateAdd" can be shared, too.

2b91699

• Unbalancing years and months can be shared, too.

128562f

• MoveRelativeDate can at most add ±200,000,000 days to the input days value, so the call to CreateDateDurationRecord is infallible.

[codecov]

Codecov Report

All modified and coverable lines are covered by tests ✅

❗ No coverage uploaded for pull request base (main@0451f32). Click here to learn what that means.

❗ Current head 128562f differs from pull request most recent head a5c5587. Consider uploading reports for the commit a5c5587 to get more accurate results

Additional details and impacted files

@@           Coverage Diff           @@
##             main    #2690   +/-   ##
=======================================
  Coverage        ?   96.22%           
=======================================
  Files           ?       20           
  Lines           ?    11986           
  Branches        ?     2227           
=======================================
  Hits            ?    11534           
  Misses          ?      389           
  Partials        ?       63           

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

[ptomato]

Thanks! These look like good simplifications, but I agree with your assessment that they will be affected substantially by the pending PRs, and one or the other will have to rebase. I'll take your advice of revisiting this after they land.

[ptomato]

I've taken another look at this now that #2727 has landed. I think a3ae84f and 2b91699 are no longer applicable because the loop is gone. That also affects the justification for 128562f, but the same 2e8 days limit applies to DaysUntil, so I think that still holds.

I had to add an extra call to LargerOfTwoTemporalUnits to account for the fact that this operation may now be called with largestUnit being a time unit (which is treated as "day") — that's the effectiveLargestUnit stuff.

I've rebased it and changed the reference code to correspond.

[anba]

That also affects the justification for 128562f, but the same 2e8 days limit applies to DaysUntil, so I think that still holds.

The call is now fallible again. The following test case calls CreateDateDurationRecord with days = 104249991374 and yearsMonthsWeeksInDays = 7. (104249991374 + 7) * 86400 is larger than 2**53, so CreateDateDurationRecord will complete with an abrupt completion.

let duration = Temporal.Duration.from({
  weeks: 1,
  days: Math.trunc((2**53) / 86_400),
});

let relativeTo = new Temporal.PlainDate(2000, 1, 1);

duration.total({
  relativeTo,
  unit: "days",
});

[ptomato]

Thanks, see tc39/test262#4007 and #2770.