March 2026 review

[waldemarhorwat]

Here's my review of the latest linked version of the proposed spec, currently dated February 24, 2026:

• It doesn't look like any of the comments from my November review have been addressed. The spec looks quite similar to that from November.

• The spec and proposal seem to have diverged. For example, there are no unit conversions in the spec.

• What happens if this is asked to display 2 meters using en-US "person" units? If I understand this class correctly, the result will be something like 79 inches, which is wrong from an internationalization perspective. If we standardize the wrong answer, it will be hard to fix it later, leading to the same user disruption we had with initially standardizing getYear, not being able to fix it without breaking existing usage, and later having to tell everyone to use getFullYear instead.

• Introduction: Extra *

• Is there a reason to collect the total number of digits in StringIntlMV? It's not used anywhere and not actually useful due to leading zeros.

• ApplyRoundingModeToPositive: Extra * on line 6

• RoundAmountValueToFractionDigits: Use the ReverseRoundingMode helper function above?

• RenderAmountValueWithFractionDigits:

  • numDigits should be fractionDigits
  • Line 8: remove the rounding code here. This function must never round. If it ever does, it's a spec bug and can generate incorrect results such as turning -0 into 0.
  • Line 9 is incorrect. As written, e will always be zero. I assume e should appear in the exponent, but then it will still always be zero because rounded is an integer. Picking the largest value here doesn't work either if, for example, v is 0.
  • Line 11 is incorrect. I can't tell what it's trying to do.
  • Line 13 is incorrect in a variety of ways. For example, n can never be positive on line e, but it can be negative.

• get Decimal.prototype.significantDigits: No one sets [[SignificantDigits]]. This should call FractionToSignificantDigits instead.

• ToIntlMathematicalValue: Spec type error on intlMV: it's a list but used as a scalar.

[sffc]

Thanks for the review!

Just to be sure @waldemarhorwat, did you review the spec currently in PR #84?

[jessealama]

It seems that the spec text you looked at wasn't what we intended. The most recent spec text work is in #85 . But it looks like the CI build step failed, causing a (re-)deployment of the old spec HTML.