Relax the ordering requirement on formatRange and selectRange functions

[sffc]

Currently, we have (or will soon have) three functions that take a range input:

1. Intl.DateTimeFormat.prototype.formatRange
2. Intl.NumberFormat.prototype.formatRange
3. Intl.PluralRules.prototype.selectRange

All of these functions currently throw a RangeError if the first argument is greater than the second argument.

This behavior was first discussed in https://github.com/tc39/proposal-intl-DateTimeFormat-formatRange/issues/1. We were inconclusive about the need at the time. Since then, some legitimate use cases have come to my attention:

1. Number ranges dealing with degrees can often be in reverse order: "45 to -45 degrees"
2. Number ranges involving all negative numbers: "stock losses ranged from -$500 to -$1000"

Potential use cases for reversed date ranges were also suggested by @nathanhammond in the original issue linked above.

In addition to use cases, @syg and @FrankYFTang have noted that the code required to enforce this constraint is fairly heavy, especially for large numbers that don't fit in a double, essentially requiring a special code path in V8. If we relaxed the constraint, a lot of code in V8 could go away or be simplified.

[ljharb]

As long as the ordering determines the sign of the result, allowing it sounds great. What we should never do is what substring does - sort the arguments.

[FrankYFTang]

Other example for the need of formatRange from large to smaller values:

1. Intl.DateTimeFormat with Temporl.PlainTime type

Real life example: " No Parking 10 PM – 6 AM" https://www.sanjoseca.gov/your-government/departments-offices/transportation/parking/parking-compliance/parking-regulations https://preview.redd.it/egv75xtdy5d11.png?width=498&format=png&auto=webp&s=5c7fb394a66e3ec69bc2b8a47b6f26f173c58e3a

2. Intl.DateTimeFormat with Temporal.PlainMonthDay type

"Here are some examples of fiscal years:

U.S. federal government: Oct. 1 to Sept. 30 Nonprofit organizations: Many use July 1 to June 30" https://www.indeed.com/career-advice/career-development/fiscal-year-vs-calendar-year

[syg]

Oo that parking sign is a great and compelling example.

[FrankYFTang]

The part which need the change are

1. https://tc39.es/ecma402/#sec-partitiondatetimerangepattern Remove step 5 "5. If x is greater than y, throw a RangeError exception. "
2. https://tc39.es/proposal-temporal/#sec-partitiondatetimerangepattern Remove step 8 "8. If x.[[epochNanoseconds]] is greater than y.[[epochNanoseconds]], throw a RangeError exception."
3. https://tc39.es/proposal-intl-numberformat-v3/out/numberformat/diff.html#sec-partitionnumberrangepattern Rework Step 2-4.
4. https://tc39.es/proposal-intl-numberformat-v3/out/pluralrules/diff.html#sec-resolvepluralrange Remove step 6 "6. If x > y, throw a RangeError exception."

[sffc]

2022-07-07 consensus: https://github.com/tc39/ecma402/blob/master/meetings/notes-2022-07-07.md#relax-the-ordering-requirement-on-formatrange-and-selectrange-functions

[sffc]

@FrankYFTang Can this issue be closed?

[sffc]

Confirmed that both Intl.NumberFormat and Intl.DateTimeFormat support arguments in both orders.