From: Maxim Cournoyer <email@example.com>
Subject: bug#59368: icecat does not honor /etc/timezone starting with 102.3.0.
Date: Tue, 14 Feb 2023 00:00:25 -0500 [thread overview]
Message-ID: <firstname.lastname@example.org> (raw)
In-Reply-To: <email@example.com> (Maxim Cournoyer's message of "Mon, 13 Feb 2023 21:13:50 -0500")
Pushing the investigation a bit, the Mozilla suite makes use of ICU to
get to know the host timezone name, and reviewing its source, I confirm
the behavior experienced. The ICU-provided
'TimeZone::detectHostTimeZone' procedure calls to 'uprv_tzname' which
first attempts to read the TZ environment variable, else expects
/etc/localtime to be a symlink.
I found another explanation for the rationale behind the /etc/localtime
being a symlink design choice :
On many systems /etc/localtime is a symlink to a timezone file. It is
conceivable that a program might be running when the /etc/localtime
symlink is updated. If this were to happen, glibc would notice this
when localtime is called and re-read the file before doing any time
This article is worth reading and further demonstrates that simply
setting the TZ environment variable can lead to a large reduction of
system calls (from 11 to 1 for a every 'time' C library call).
So the choice to make here for Guix would be:
1. Do as most other distributions and have /etc/localtime be a symlink
pointing to the timezone file.
2. Set TZ and reap some performance benefits.
The disadvantage of going with 2. is that users would then require to
restart their system following a reconfiguration changing their time
zone, which is not user friendly.
So I think I'd go with 2, knowing that savvy users wanting to shave some
extra resources can always set the TZ environment variable themselves.
next prev parent reply other threads:[~2023-02-14 5:01 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-11-18 19:50 bug#59368: icecat does not honor /etc/timezone starting with 102.3.0 Maxim Cournoyer
2023-02-13 22:17 ` Maxim Cournoyer
2023-02-14 2:13 ` Maxim Cournoyer
2023-02-14 5:00 ` Maxim Cournoyer [this message]
2023-02-14 16:32 ` Maxim Cournoyer
2023-02-14 16:34 ` Maxim Cournoyer
2023-02-15 2:45 ` Maxim Cournoyer
2023-02-15 19:00 ` Jonathan Brielmaier
2023-02-15 19:50 ` Maxim Cournoyer
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
List information: https://guix.gnu.org/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this public inbox
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).