Intl.NumberFormat compact notation leaves out comma

[maxsultan-aumni]

This only happens for numbers in the trillions in compact mode as other numbers increase the letter

const format = (val) =>
  new Intl.NumberFormat("en-US", {
    style: "currency",
    currency: "USD",
    notation: "compact",
    useGrouping: true,
  }).format(val);

console.log(format(1111111222333444)); // $1111T

if you add a single digit to that number, then it adds the comma as expected. but with 4 digits in compact mode there is no comma

const format = (val) =>
  new Intl.NumberFormat("en-US", {
    style: "currency",
    currency: "USD",
    notation: "compact",
    useGrouping: true,
  }).format(val);

console.log(format(11111111222333444)); // $11,111T

[sffc]

This issue is not newly introduced in Intl.NumberFormat v3, so I'm moving this to the main repo.

The spec states the following:

b. Let groups be a List whose elements are, in left to right order, the substrings defined by ILND set of locations within the integer.

NFv3 adds

which may depend on the value of numberFormat.[[UseGrouping]].

So if we desire to make the current behavior conformant to the spec, this could be done by changing that line to make clear that it could also depend on the Notation setting. However, the status quo is probably fine the way it is.

[sffc]

Thoughts @gibson042?

[gibson042]

I don't want to make that behavior nonconformant. Updating the step to clarify possible dependence upon configuration works for me.

[maxsultan-aumni]

So if I understand correct you're saying we could get this formatted as '$1,111T' based on a different configuration object? Can you show me what that would look like? It's not clear to me from reading the spec

[sffc]

There are two questions to answer:

1. What is the correct behavior?
2. Which behaviors should ECMA-402 allow?

I'm currently suggesting that the spec should allow the currently observed behavior, regardless of what the correct behavior might be.

However, to revisit the first question, then UTS 35 spec states:

N is divided by 1000 (obtained from 10000 after removing "00" and restoring one "0"). The result is formatted according to the normal decimal pattern. With no fractional digits, that yields "12 K".

https://unicode.org/reports/tr35/tr35-numbers.html#Compact_Number_Formats

which suggests that "$1,111T" is the expected behavior; we shouldn't lose the grouping separator. That would be a bug in ICU, not in ECMA-402.

I filed a ticket: https://unicode-org.atlassian.net/browse/ICU-22254

[maxsultan-aumni]

@sffc I see, thank you for the clarification 🙏

[sffc]

Also, note that in the latest Chrome release, you are getting your desired behavior due to the NumberFormat v3 proposal changing the semantics of useGrouping: true to be more strict.

[sffc]

Discussed in 2024-03-28 TG2 meeting. We're having trouble reproducing the undesired behavior, and would note that it is allowed by the spec regardless. So I will close this issue.

[sffc]

TG2 notes: https://github.com/tc39/ecma402/blob/main/meetings/notes-2024-03-28.md#intlnumberformat-compact-notation-leaves-out-comma-751