Repository navigation
Intl.DateTimeFormat().resolvedOptions().timeZone undefined on MacOS 14.0 (Sonoma) #50301
Description
Activity
Can't reproduce. Am I missing something?
$ sw_vers ProductName: macOS ProductVersion: 14.0 BuildVersion: 23A344 $ node Welcome to Node.js v18.18.2. Type ".help" for more information. > new Intl.DateTimeFormat().resolvedOptions().timeZone // undefined 'CET'@gimyboya what does
echo $TZprint on your system?You can probably work around the issue by setting TZ to some known-good value, for example:
$ env TZ=Europe/Amsterdam node app.js@bnoordhuis TZ is not set in my environment.
From looking at the V8 issue, it seems related to the ICU version. @gimyboya how did you install Node.js on your machine?
The official binaries are statically linked to ICU 73. Maybe your version is not?From looking at the V8 issue, it seems related to the ICU version. @gimyboya how did you install Node.js on your machine? The official binaries are statically linked to ICU 73. Maybe your version is not?
@targos I am using nvm 0.39.1 to install different node versions. and TZ is not set in my environment.
We are also getting this. 18.18.2 returns undefined, 18.16.0 returns the correct value. using nvm aswell.
It looks like the fix is actually in ICU 74.
Reacted by Jithil P Ponnan and Dmitriy GavrilovI'm pretty certain this affects Node >= 18.18.2
So, should we wait for the ICU next release? Or patch it to Node >= 18.18.2 ?
Please let me know, I can work on it.
FWIW we have docs on how to float patches for ICU: https://github.com/nodejs/node/blob/main/doc/contributing/maintaining/maintaining-icu.md#floating-patches-to-icu
It's not just a case of cherry-picking -- some reasoning was documented in https://github.com/nodejs/node/blob/main/doc/contributing/maintaining/maintaining-icu.md#why-not-just-modify-the-icu-source-directlyReacted by Michaël Zasso@targos been trying to ping you folks. 74 is in RC and I already landed a fix to it that had broken the node build. So I'd wait at this point
unicode-org/icu#2664 is the pr that un breaks the nodejs build.
Reacted by Jithil P PonnanIf you are going to want this in a prior icu version I'd recommend asking about that on the icu ticket. Even if icu doesn't release a prior patch, they might put a commit on the icu maint branch which could be picked up . I might even suggest contributing the back port there as a pr if someone is inclined. (I could see the argument for this being back ported)
Yes. I can create a patch to all the impacted versions.
Yes. I can create a patch to all the impacted versions.
I know you can. But what I'm recommending instead is replying on the upstream ICU ticket and asking about backports to prior versions. For example against branch https://github.com/unicode-org/icu/tree/maint/maint-73
Basically, contribute it upstream - open a PR against that maint-73 branch instead of just doing the backporting downstream in Node. Then you'll have an exact patch to take from. Maybe even ICU would be willing to backport it, not sure
[sorry hit the wrong button, didn't mean to close]
Reacted by Jithil P PonnanYes. I can create a patch to all the impacted versions.
I know you can. But what I'm recommending instead is replying on the upstream ICU ticket and asking about backports to prior versions. For example against branch https://github.com/unicode-org/icu/tree/maint/maint-73
Basically, contribute it upstream - open a PR against that maint-73 branch instead of just doing the backporting downstream in Node. Then you'll have an exact patch to take from. Maybe even ICU would be willing to backport it, not sure
[sorry hit the wrong button, didn't mean to close]
You mean, something like this ? unicode-org/icu#2681
FYI - This has now been resolved by Apple (All previously broken versions of node work on both 14.3 and 14.4). So this issue can be closed.
Reacted by Al-KhawarizmiYes. I can create a patch to all the impacted versions.
I know you can. But what I'm recommending instead is replying on the upstream ICU ticket and asking about backports to prior versions. For example against branch https://github.com/unicode-org/icu/tree/maint/maint-73
Basically, contribute it upstream - open a PR against that maint-73 branch instead of just doing the backporting downstream in Node. Then you'll have an exact patch to take from. Maybe even ICU would be willing to backport it, not sure
[sorry hit the wrong button, didn't mean to close]You mean, something like this ? unicode-org/icu#2681
yes, but it's still draft.
FYI - This has now been resolved by Apple (All previously broken versions of node work on both 14.3 and 14.4). So this issue can be closed.
in any event, the backport is proposed there in ICU as well.
Version
v18.18.2
Platform
Darwin MacBook-Pro.local 23.0.0 Darwin Kernel Version 23.0.0: Fri Sep 15 14:42:42 PDT 2023; root:xnu-10002.1.13~1/RELEASE_X86_64 x86_64
Subsystem
Intl.DateTimeFormat().resolvedOptions().timeZone
What steps will reproduce the bug?
Executing the following code would yield
undefinedHow often does it reproduce? Is there a required condition?
As long as it's on MacOS 14.0 (Sonoma) it will always return
undefinedWhat is the expected behavior? Why is that the expected behavior?
I expect to get back a properly resolved timezone. as that's how
Intlis supposed to workWhat do you see instead?
I get an
undefinedAdditional information
This is currently a known bug that chrome was facing as well since MacOS 14.0 (Sonoma) changed the way to resolve Timezones as you can see here js-temporal/temporal-polyfill#264 (comment)