Re: [musl] Time zone has not updated after call tzset()

["alice" <alice@ayaya.dev>]

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