You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
Number.toLocaleString output is inconsistent between minor versions. #21053
Output of Number.toLocaleString is inconsistent since version v10.3.0
Versions prior to v10.3.0 have consistent output. Tested with v8.11.2, v9.0.0, v10.0.0, v10.2.1
Yes… this was intended to be a fix of a bug that presented itself somewhere between v7.9.0 and v8.4.0 (#15223). I personally don’t believe the bug fix was a breaking change that warrants semver-major, but I do realize that it has the potential to break some test suites, so apologies about that.
I don’t think there is much we can do right now though. After all a revert would just make the problem worse (another such change in the v10.x branch).
@srl295 Maybe, but you'd expect the same result on the same locale between node versions, right? We noticed the issue upgrading to node 10+ so we ended up removing the usage of locale, unfortunately.
@srl295 Maybe, but you'd expect the same result on the same locale between node versions, right? We noticed the issue upgrading to node 10+ so we ended up removing the usage of locale, unfortunately.
I just started testing Node 10 for planned migration from Node 8. Noticed that Date.toLocaleString("iso") now behaves differently. Under Node 8 I would get "2019-03-12 12:34:56" but under Node 10+ I am getting "03/12/2019 12:34:56 PM". Funny thing is I am trying to find the old reference to "iso" as a valid locale and I am having no luck. I suspect it may have been expunged. However, toLocaleString() does not throw an error with it like it does for other invalid locales.
Activity
tniessen commentedon May 31, 2018
Failed to reproduce on Ubuntu 16.04:
silverwind commentedon May 31, 2018
Please show
process.config.variablesandprocess.versionson both versions.ken210 commentedon May 31, 2018
v10.2.1
v10.3.0
silverwind commentedon May 31, 2018
Interesting, same ICU version and build but different output. Any idea @nodejs/intl?
vsemozhetbyt commentedon May 31, 2018
Cannot reproduce with Windows builds:
https://nodejs.org/download/release/v10.2.1/win-x64/
https://nodejs.org/download/release/v10.3.0/win-x64/
devsnek commentedon May 31, 2018
can repro on mac
devsnek commentedon May 31, 2018
i would guess this is related to #20826
/cc @TimothyGu
TimothyGu commentedon May 31, 2018
Yes… this was intended to be a fix of a bug that presented itself somewhere between v7.9.0 and v8.4.0 (#15223). I personally don’t believe the bug fix was a breaking change that warrants semver-major, but I do realize that it has the potential to break some test suites, so apologies about that.
I don’t think there is much we can do right now though. After all a revert would just make the problem worse (another such change in the v10.x branch).
silverwind commentedon May 31, 2018
Closing based on #21053 (comment).
srl295 commentedon Jun 1, 2018
test suites should not expect specific 'golden' results for locale data.
msegers commentedon Feb 6, 2019
@srl295 Maybe, but you'd expect the same result on the same locale between node versions, right? We noticed the issue upgrading to node 10+ so we ended up removing the usage of locale, unfortunately.
Whobeu commentedon Mar 12, 2019
I just started testing Node 10 for planned migration from Node 8. Noticed that Date.toLocaleString("iso") now behaves differently. Under Node 8 I would get "2019-03-12 12:34:56" but under Node 10+ I am getting "03/12/2019 12:34:56 PM". Funny thing is I am trying to find the old reference to "iso" as a valid locale and I am having no luck. I suspect it may have been expunged. However, toLocaleString() does not throw an error with it like it does for other invalid locales.