Spec Text Size Reductions: Tracking Ticket

[arshaw]

This ticket tracks progress for all other tickets meant to reduce the number of calls to user code repeated sections of the spec text. These are/will be implemented as merely PROOFS OF CONCEPT at first. The original goal of this was to improve runtime performance and reduce user code calls. Now the goal is to make the code more DRY for decreased proposal size and file size of compiled code in implementations.

• Fewer CalendarDateAdd/DateUntil calls during relative rounding #2792 (test262 diff)
  • Blocked on Normative: Fix Duration rounding relative to ZonedDateTime #2758
  • Size reduction: HIGH
• Fewer CalendarDateAdd/DateUntil calls during day-rounding w/ PlainDate #2791 (test262 diff)
  • Blocked on Fewer CalendarDateAdd/DateUntil calls during relative rounding #2792
  • Size reduction: NONE
• Fewer GetOffsetNanosecondsFor calls during InterpretISODateTimeOffset (prefer/reject) #2789
  • Size reduction: NONE
• Fewer CalendarDay/CalendarDateFromFields calls during PlainYearMonth add/subtract #2798
  • Size reduction: LOW

Bugs

Tickets that BOTH require bugfixing AND will decrease # of user calls and reduce filesize when fixed:

• Normative: Fix ZonedDateTime::round incorrect results with smallestUnit:day #2797
  • Size reduction: LOW
• Normative: [Alt PR] Fix intermediate value in ZonedDateTime difference #2810 (test262 diff)
  • Size reduction: NONE
• Normative: Fix Duration rounding relative to ZonedDateTime #2758 (need test262 diff)
  • Size reduction: MEDIUM

Other DRY-ness

In addition to above, there are other ways to make the code more DRY:

• Unify code paths for YMD diffing:
  • Size reduction: MEDIUM
  • reference polyfill (ISO: DifferenceISODate, Intl: nonIsoHelperBase.untilCalendar) VS fullcalendar polyfill (combined: diffYearMonthDay)
• Options parsing for diffing rounding (roundingIncrement, roundingMode)
  • maximumIncrements/MAX_DIFFERENCE_INCREMENTS

[ptomato]

As of #2826, we are getting rid of user code calls, so let's change the focus of this to just DRY the spec algorithms. Once #2826 happens, these should all be editorial changes, so they are less urgent; we should get them incorporated before declaring the spec stable though.