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
Wrong Intl.DateTimeFormat output for zh-CN without year part #29596
@bnoordhuis I guess your system locale is en-US or similar (mine is zh-CN). If I run node v12.10.0 with a overwritten locale(LANG=en-US node), I get '09/16' too. This behavior surprises me because I thought Intl.DateTimeFormat did not depend on system locale.
Hm, right. I reverted the ICU upgrade in my local v10.x branch and it indeed makes no difference.
I suppose that means a change in V8 is responsible (or the interaction between ICU and V8) but the diff between V8 6.8 and 7.6 is so big that it's hopeless to isolate the change.
There are plans to bundle full-icu with Node.js (#19214) so this issue will probably become moot in the not too distant future.
Omitting the timeZone option doesn't change those results for me:
Yes, I should have said "timezone or locale." (I did refer to the locale in the next sentence but not the first one.)
Sounds good to me. For now my workaround is adding a year: "numeric" option and picking month and date parts from the result. Feel free to close this issue.
Activity
ex1st commentedon Sep 18, 2019
Node v12.10.0
Node v12.10.0 with full-icu
duanyao commentedon Sep 18, 2019
I have verified that both v12.10.0 and v10.14.2 I tested are with small-icu, according to https://nodejs.org/docs/latest-v10.x/api/intl.html
v10.x is ok for Intl.DateTimeFormat + zh-CN but 12.x is not.
bnoordhuis commentedon Sep 18, 2019
Can't reproduce. Both master and v12.10.0 with small-icu pritn
'09/16'for me.edit: and to be clear: yes, that's a slash, not a dash.
duanyao commentedon Sep 19, 2019
@bnoordhuis I guess your system locale is en-US or similar (mine is zh-CN). If I run node v12.10.0 with a overwritten locale(
LANG=en-US node), I get'09/16'too. This behavior surprises me because I thought Intl.DateTimeFormat did not depend on system locale.bnoordhuis commentedon Sep 19, 2019
With
LANG=zh-CNI can reproduce. Seems to be caused by the upgrade to ICU 64.2 in #27361 which means v10.16.0 and newer are also affected.I don't know if it's actually a bug but @srl295 can probably shed some light on that.
It does when ICU doesn't know the timezone name you pass to
Intl.DateTimeFormat.Fixing the fallback locale to some known-good value has been discussed in the past but being able to override it is sometimes useful.
duanyao commentedon Sep 19, 2019
@bnoordhuis I checked v10.16.3 and it doesn't affected (https://nodejs.org/dist/v10.16.3/node-v10.16.3-linux-x64.tar.xz ).
Omitting the
timeZoneoption doesn't change those results for me:bnoordhuis commentedon Sep 19, 2019
Hm, right. I reverted the ICU upgrade in my local v10.x branch and it indeed makes no difference.
I suppose that means a change in V8 is responsible (or the interaction between ICU and V8) but the diff between V8 6.8 and 7.6 is so big that it's hopeless to isolate the change.
There are plans to bundle full-icu with Node.js (#19214) so this issue will probably become moot in the not too distant future.
Yes, I should have said "timezone or locale." (I did refer to the locale in the next sentence but not the first one.)
duanyao commentedon Sep 19, 2019
Sounds good to me. For now my workaround is adding a
year: "numeric"option and picking month and date parts from the result. Feel free to close this issue.bnoordhuis commentedon Sep 19, 2019
Okay, I'll go ahead and do that.
For everyone coming here through search engines: installing the full-icu package should fix this in a forward compatible manner.