Repository navigation
Time zone issue on Date #50565
Description
Activity
I have tested on my PC, which time zone is
(UTC +08:00) Beijing, Chongqing, Hongkongon node 20.9.0, but didn't reproduce your issue, also tried byconst options = { timeZone: 'Asia/Shanghai' }; const formatter = new Intl.DateTimeFormat('en-US', options);
I can't reproduce it in Node.js 20.8.0 on Linux:
$ TZ='Asia/Shanghai' node -p '[new Date().toString(), process.versions.node]' [ 'Mon Nov 06 2023 01:25:02 GMT+0800 (China Standard Time)', '20.8.0' ]
May be related to #50301 which is macOS specific.
Cannot reproduce on macOS ventura
TZ='Asia/Shanghai' node -p '[new Date().toString(), process.versions.node]'
[ 'Mon Nov 06 2023 19:23:49 GMT+0800 (China Standard Time)', '20.2.0' ]May be related to #50301 which is macOS specific.
See also https://unicode-org.atlassian.net/browse/ICU-22541. Possibly fixed in ICU 74.1 but #50515 will need work to land.
Cannot reproduce on macOS ventura
TZ='Asia/Shanghai' node -p '[new Date().toString(), process.versions.node]'[ 'Mon Nov 06 2023 19:23:49 GMT+0800 (China Standard Time)', '20.2.0' ]I execute your command, and it also works for me. Have to set the time zone of macOS to 'Asia/Shanghai' with this command:
sudo systemsetup -settimezone Asia/Shanghai, this issue would be reproducedMay be related to #50301 which is macOS specific.
See also https://unicode-org.atlassian.net/browse/ICU-22541. Possibly fixed in ICU 74.1 but #50515 will need work to land.
It's good, should I close this issue?
I'll go ahead and close this. Summary: upstream bug fixed in newer versions. Upgrade pending.
May be related to #50301 which is macOS specific.
See also https://unicode-org.atlassian.net/browse/ICU-22541. Possibly fixed in ICU 74.1 but #50515 will need work to land.
Any work besides the unit test failures? FyI @sven-oly
Quick Question for those who know how ICU updates work: Will this end up being backported to current LTS? We are holding off upgrading to 20.x as the majority of our dev team is now on Sonoma. I assume 74.1 won't end up in LTS, but could a patch to 73 go in?
Reacted by Steven R. LoomisQuick Question for those who know how ICU updates work: Will this end up being backported to current LTS? We are holding off upgrading to 20.x as the majority of our dev team is now on Sonoma. I assume 74.1 won't end up in LTS, but could a patch to 73 go in?
I'm not sure let me ask about a dot release or patch. I've asked if there's a patch against 73.
Does anyone know whether 74 could land in LTS or not? Landing 74 would be easier.
Version
v20.9.0
Platform
Darwin Devins-MacBook-Air-m2-2022.local 23.0.0 Darwin Kernel Version 23.0.0: Fri Sep 15 14:42:57 PDT 2023; root:xnu-10002.1.13~1/RELEASE_ARM64_T8112 arm64
Subsystem
No response
What steps will reproduce the bug?
sudo systemsetup -settimezone Asia/Shanghaiconsole.log(new Date().toString().node timezone.jsMon Nov 06 2023 00:19:33 GMT+0800 (Central Standard Time)
How often does it reproduce? Is there a required condition?
No response
What is the expected behavior? Why is that the expected behavior?
The name of time zone in China is China Standard Time instead of Central Standard Time, the exprected output should be: Mon Nov 06 2023 00:19:33 GMT+0800 (China Standard Time)
What do you see instead?
This Output would display on the terminal
Mon Nov 06 2023 00:19:33 GMT+0800 (Central Standard Time)
Additional information
No response