From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on inbox.vuxu.org X-Spam-Level: X-Spam-Status: No, score=-1.0 required=5.0 tests=MAILING_LIST_MULTI, RCVD_IN_MSPIKE_H2 autolearn=ham autolearn_force=no version=3.4.4 Received: (qmail 8140 invoked from network); 11 Feb 2023 14:20:50 -0000 Received: from second.openwall.net (193.110.157.125) by inbox.vuxu.org with ESMTPUTF8; 11 Feb 2023 14:20:50 -0000 Received: (qmail 1269 invoked by uid 550); 11 Feb 2023 14:20:48 -0000 Mailing-List: contact musl-help@lists.openwall.com; run by ezmlm Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-ID: Reply-To: musl@lists.openwall.com Received: (qmail 1232 invoked from network); 11 Feb 2023 14:20:47 -0000 Date: Sat, 11 Feb 2023 09:20:35 -0500 From: Rich Felker To: alice Cc: musl@lists.openwall.com, "yubing (C)" , liudongxu , "wangyunhe (A)" , qiuguorui , "Wanglieming (VRP SSP)" Message-ID: <20230211142034.GF4163@brightrain.aerifal.cx> References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Subject: Re: [musl] Time zone has not updated after call tzset() 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: 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