Currency-derived fractional digit count defaults are inappropriately applied with scientific/engineering/etc. notation
#912
Labels
Comments
gibson042
changed the title
notation
gibson042
changed the title
notationnotation
|
Currency formatting with engineering notation, is that a real-world issue? |
|
I would support a PR tweaking this behavior. |
sffc
added
s: discuss
ben-allen
added a commit
to ben-allen/ecma402
that referenced
this issue
Sep 17, 2024
…er of fractional units used to display that currency when using standard notation. Previously this data was inappropriately used when using scientific, engineering, and compact notations. See issue tc39#912.
ben-allen
added a commit
to ben-allen/ecma402
that referenced
this issue
Sep 17, 2024
…er of minor units used to display that currency when using standard notation. Previously this data was inappropriately used to set the number of fractional digits displayed when formatting currency values in scientific, engineering, and compact notations. See issue tc39#912.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
(originally posted by @gibson042 in #839 (comment) )
We arguably have a bug where currency-derived fractional digit count defaults are applied even when the decimal point is moved away from its absolute position, as in
new Intl.NumberFormat("en", { style: "currency", currency, currencyDisplay: "code", notation: "engineering" }).format(12345).replace(/^.*\s/, "")resulting in "12E3" for JPY but "12.35E3" for USD).Put another way, I think I expect currency-derived precision and corresponding rounding to apply only when
notationis "standard" (i.e., not even when the decimal point happens to be in the right place with scientific/engineering/compact notation).The text was updated successfully, but these errors were encountered: