/etc/localtime symlink handling

[mat8913]

• Version: v11.7.0
• Platform: Linux gallium 4.19.25 1-NixOS SMP PREEMPT Sat Feb 23 08:07:27 UTC 2019 x86_64 GNU/Linux
• Subsystem:

Node has trouble figuring out the timezone if /etc/localtime is an indirect symlink. Here's some examples in the REPL

> Date()
'Sun Mar 24 2019 01:42:40 GMT+1000 (GMT+10:00)'    # Wrong, it's GMT+11 in Sydney right now
> new Date().toLocaleString()
'3/24/2019, 1:42:55 AM'                            # Similarly to above
> Intl.DateTimeFormat().resolvedOptions().timeZone
undefined

Even worse, in electron:

> new Date().toLocaleString()
VM575:1 Uncaught RangeError: Unsupported time zone specified undefined
    at new DateTimeFormat (native)
    at Date.toLocaleString (native)
    at <anonymous>:1:12

This is the cause of FreeTubeApp/FreeTube#233. It might also be the cause of ValveSoftware/steam-for-linux#5609 and flathub/im.riot.Riot#32.

[bnoordhuis]

I'm reasonably sure this is an upstream ICU issue since Node.js itself doesn't directly read or manipulate /etc/localtime.

ICU on the other hand does and in fact calls readlink() on many/most Unices. The logic is in deps/icu-small/source/common/putil.cpp.

cc @srl295

[targos]

Is there an easy way to reproduce? Maybe in a Docker container?

[jasnell]

ping @srl295

[srl295]

Definitely ICU. I've fixed a lot of this code, and nixos is what most of my linuxes run but with an explicit TZ. Let me try to repro.

[srl295]

@mat8913 can you give me the relevant part of your nix config?

[srl295]

@mat8913

• how was Node built/isntalled?

• 11.7.0 should be ICU 63.1 - but can you give the output of node -p process.versions ?

• I try running this:

$ nix-env  -iA nixos.icu63
$ /nix/store/*-icu4c-63.1-dev/bin/icuinfo
…
    <param name="tz.default">America/Los_Angeles</param>
…

What do you get if you run the icuinfo command above? Is it correct?

I don't see any relevant patches in https://github.com/NixOS/nixpkgs/blob/master/pkgs/development/libraries/icu/base.nix

[srl295]

@mat8913
What do you get if you run the icuinfo command above? Is it correct?

If it's wrong above, then definitely file an issue at https://unicode-org.atlassian.net/ under ICU

for reference, i am on:

Linux qrendi 5.4.42 #1-NixOS SMP Wed May 20 06:20:41 UTC 2020 x86_64 GNU/Linux
Nixos 20.03.1996.fc60ed1fffb (Markhor)

[srl295]

@mat8913 if its helpful. the workaround would be to set TZ=Australia/Sydney

[mat8913]

@srl295 On NixOS, the problem occurs in buildFHSUserEnvs (such as steam-run for example) where /etc/localtime is a symlink into the nix store.

The problem also occurs in flatpaks where /etc/localtime is a symlink to /run/host/monitor/localtime, but I think the flatpak maintainers are changing it to be a direct symlink soon.

Your suggested workaround of setting TZ does indeed work and is what I'm using in NixOS/nixpkgs@2a842a1 for example.

@targos Here's a Dockerfile to reproduce (well, I actually run it in podman but I think the syntax is the same):

FROM docker.io/library/node:latest
RUN ln -s zoneinfo /usr/share/test
RUN ln -sf /usr/share/test/Australia/Sydney /etc/localtime
CMD icuinfo; echo 'console.log(Intl.DateTimeFormat().resolvedOptions().timeZone)' | node -

Output on my computer is

Plugins are disabled.
 <icuSystemParams type="icu4c">
    <param name="copyright"> Copyright (C) 2016, International Business Machines Corporation and others. All Rights Reserved. </param>
    <param name="product">icu4c</param>
    <param name="product.full">International Components for Unicode for C/C++</param>
    <param name="version">57.1</param>
    <param name="version.unicode">8.0</param>
    <param name="platform.number">4000</param>
    <param name="platform.type">Linux</param>
    <param name="locale.default">en_US_POSIX</param>
    <param name="locale.default.bcp47">en-US-u-va-posix</param>
    <param name="converter.default">US-ASCII</param>
    <param name="icudata.name">icudt57l</param>
    <param name="icudata.path"></param>
    <param name="cldr.version">29.0</param>
    <param name="tz.version">2016b</param>
    <param name="tz.default">AEST</param>
    <param name="cpu.bits">64</param>
    <param name="cpu.big_endian">0</param>
    <param name="os.wchar_width">4</param>
    <param name="os.charset_family">0</param>
    <param name="os.host">x86_64-pc-linux-gnu</param>
    <param name="build.build">x86_64-pc-linux-gnu</param>
    <param name="build.cc">gcc</param>
    <param name="build.cxx">g++</param>
    <param name="uconfig.internal_digitlist">1</param>
    <param name="uconfig.have_parseallinput">1</param>
    <param name="uconfig.format_fastpaths_49">1</param>
 </icuSystemParams>


ICU Initialization returned: U_ZERO_ERROR
undefined

[srl295]

@mat8913 sorry, been away/job change/etc.

<param name="tz.default">AEST</param>

This doesn't sound right. It should be an ID such as Australia/Sydney.

RUN ln -sf /usr/share/test/Australia/Sydney /etc/localtime

There's a rant in here somewhere.
But what happens in some cases is cp /usr/share/test/Australia/Sydney /etc/localtime - what we have to do is compare EVERY file in zoneinfo to see if the contents match /etc/localtime. In this case, we don't know what root to use, ICU may not be checking /etc/localtime/.

/usr/share/test/Australia/Sydney is now a symlink to ACT … how am I supposed to know that you meant Australia/Sydney?

The rant is this: tz files ought to be self identifying. See some concrete proposals by me in https://mm.icann.org/pipermail/tz/2017-February/024815.html

The root cause within ICU is this:

• ICU may be not checking the double symlink?
• ICU may not know about /run/host/monitor as a source for tz files.

The relevant ICU code is here: https://github.com/unicode-org/icu/blob/master/icu4c/source/common/putil.cpp#L702

Can you file an issue under https://unicode-org.atlassian.net/ and reference this one? I'm stepping back from ICU for a bit so I don't know when I will get to this, but ICU's PRs are open… 

[srl295]

@mat8913 and forgot to mention, thanks for a very clear reproducible case. 👍 👍
Anyone from @nodejs/i18n-api want to help dive into this?