[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-Id: <CQFT11F50VT0.PKIXH946RVEX@sumire>
Date: Sat, 11 Feb 2023 15:30:58 +0100
From: "alice" <alice@...ya.dev>
To: "Rich Felker" <dalias@...c.org>
Cc: <musl@...ts.openwall.com>, "yubing (C)" <yubing12@...wei.com>,
"liudongxu" <liudongxu3@...wei.com>, "wangyunhe (A)"
<wangyunhe@...wei.com>, "qiuguorui" <qiuguorui1@...wei.com>, "Wanglieming
(VRP SSP)" <wanglieming@...wei.com>
Subject: Re: Time zone has not updated after call tzset()
On Sat Feb 11, 2023 at 3:20 PM CET, Rich Felker wrote:
> On Sat, Feb 11, 2023 at 03:10:40PM +0100, alice wrote:
> > On Sat Feb 11, 2023 at 7:53 AM CET, zhoujingqiang (A) wrote:
> > > Hello,
> > >
> > > Normally, /etc/localtime is a soft link to a file that stores time zone
> > > information.
> > >
> > > Without setting the TZ environment variable, I change the time zone by
> > > changing the file linked to /etc/localtime. After calling tzset(), I find that
> > > the time zone does not change. The test code is as follows:
> >
> > musl does not support changing the timezone while running.
> > see https://www.openwall.com/lists/musl/2017/06/09/9 ,
> > for a response to an identical bug report
> >
> > tl;dr without semantics: you have to restart a running process to get a new
> > timezone.
>
> This is not quite accurate. It does, but only via application intent,
> in the form of changing its value of TZ. It does not re-scan files if
> the application doesn't do that, for two important reasons:
yes, with the semantics, something like:
setenv("TZ", "something", 0);
tzset();
unsetenv("TZ");
will update to a new /etc/localtime symlink. it's mentioned in
https://marc.info/?l=musl&m=141374003126007&w=2
from the above thread.
(apologies, i worded that poorly; what i mean is you cannot rely on /
etc/localtime being read on update (without the hack above), which was the
question. setenv("TZ") is also supported, of course.)
> 1. Without explicit action by the application, there is no way to
> synchronize changes to the timezone with application consumption of
> the timezone. Operations like localtime, [some adjustment], mktime
> will give erroneous results under a race where the zone changes
> between the calls. (One might suggest using calls to tzset to
> synchronize, but POSIX specifies that all the functions which use
> time zone behave as if they implicitly called tzset, so this seems
> to be forbidden, and it wouldn't be thread-safe anyway.)
>
> 2. Re-scanning the file on disk every time an operation using the time
> zone is performed results in abysmal performance. This is a
> bottleneck for lots of programs that do any kind of logging, and if
> I recall it was the topic of a longstanding, user-infuriating bug
> report against glibc.
>
> Rich
Powered by blists - more mailing lists
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
