Proposal to limit rounding increments for hour, month, week, and day

[ptomato]

Feedback from @anba in #1502:

Unlimited increment for "hour", "month", "week", and "day" has some issues:

1. Too large increments don't seem useful for the user, because the other input is always restricted to a certain range. For example the number of days between two dates is restricted to 2×10⁸ days by definition. When the rounding increment is then set to, let's say 10⁹, the rounding result will always either be 0 or 10⁹, depending on the rounding mode. (Or in other cases TypeErrors, because some intermediate results can't be represented.)
2. And unlimited increments make harder to implement this, because it's not possible to use fixed size integer types.

Therefore I'd like to propose to limit the maximum rounding increment for "hour", "month", "week", and "day" to reasonable limits.

(My apologies for not noticing and pulling this out of the checklist earlier.)

Example of what's being referred to in (1):

Temporal.PlainDate.from('2023-01-05').until('2023-01-06', {roundingIncrement: 1e9})
  // => PT0S
Temporal.PlainDate.from('2023-01-05').until('2023-01-06', {roundingIncrement: 1e9, roundingMode: 'ceil'})
  // => P1000000000D

[ptomato]

Personally, I'm not in favour of this; one person's reasonable limit is another's unreasonable restriction.

Would the storage issue (2) be able to be solved by using a double, since the increment is guaranteed to originate as a JS Number?

[justingrant]

Meeting 2023-01-12: we'll limit all currently-unlimited increments to 10⁹ (or lower) so they can fit in a 32-bit integer. We'll use 10⁹ instead of 2³¹-1 or 2³²-1 because 10⁹ will be clearer in end-user-facing documentation.