/etc/localtime symlink handling

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.

@srl295

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

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

@srl295

ping @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.

@mat8913

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

@mat8913

@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

@mat8913

@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)

@mat8913

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

@srl295

@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

@mat8913

@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…

@mat8913

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

@Mhmoni25 are you able to try running icuinfo locally?

Do you know how the multiple symlinks got there? It would be best to only use TZ=Australia/Sydney as I mentioned, or, a single symlink. The tz database project has declined (lack of resources, and I wasn't able to make a full proposal) to include the zone id within the data file. So it's always been a sort of wild goose chase to try to get the needed information out of the symlinks and their location.

If someone wants to improve things here, the best course of action is to contribute to ICU. It looks like there's actually an ICU bug filed: ICU-21386.

Mhmoni25's entire comment merely quotes mat8913 and adds nothing. It is similar to their comment at #42058 (comment). Their other comments across GitHub (such as mdn/browser-compat-data#14194 and dapphub/dappsys#63) are spam. They are now blocked from the organization.

Good working tools

Good working tools

This user is now blocked too.

This issue has been marked as stale due to 210 days of inactivity.
It will be automatically closed in 30 days if no further activity occurs. If this is still relevant, please leave a comment or update it to keep it open.

This issue has been automatically closed after 30 days of inactivity following its stale status (no activity for a total of 120 days).
If this is still relevant, feel free to reopen it or leave a comment with additional details so we can continue the discussion.

Navigation Menu

Repository navigation

/etc/localtime symlink handling #26880

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

/etc/localtime symlink handling #26880

Description

Activity

bnoordhuis commented on Mar 24, 2019

targos commented on Jun 13, 2020

jasnell commented on Jun 26, 2020

srl295 commented on Jun 26, 2020

srl295 commented on Jun 26, 2020

srl295 commented on Jun 26, 2020

srl295 commented on Jun 26, 2020

srl295 commented on Jun 26, 2020

mat8913 commented on Jun 27, 2020

srl295 commented on Jul 8, 2020

srl295 commented on Jul 8, 2020

Mhmonicox commented on Jul 9, 2021

srl295 commented on Jul 9, 2021

Trott commented on Feb 20, 2022

Ikaberry202 commented on Apr 9, 2022

Trott commented on Apr 9, 2022

github-actions commented on Jun 27, 2026

github-actions commented on Jul 28, 2026

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions