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=-3.3 required=5.0 tests=MAILING_LIST_MULTI, RCVD_IN_DNSWL_MED,RCVD_IN_MSPIKE_H3,RCVD_IN_MSPIKE_WL autolearn=ham autolearn_force=no version=3.4.4 Received: (qmail 8251 invoked from network); 25 Apr 2021 18:39:14 -0000 Received: from mother.openwall.net (195.42.179.200) by inbox.vuxu.org with ESMTPUTF8; 25 Apr 2021 18:39:14 -0000 Received: (qmail 9617 invoked by uid 550); 25 Apr 2021 18:39:11 -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 9599 invoked from network); 25 Apr 2021 18:39:10 -0000 Date: Sun, 25 Apr 2021 14:38:57 -0400 From: Rich Felker To: =?utf-8?B?U8O2cmVu?= Tempel Cc: musl@lists.openwall.com Message-ID: <20210425183841.GU2546@brightrain.aerifal.cx> References: <2V3462FZGWFIY.1YKM4G9ZM41UC@8pit.net> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <2V3462FZGWFIY.1YKM4G9ZM41UC@8pit.net> User-Agent: Mutt/1.5.21 (2010-09-15) Subject: Re: [musl] Handling of non-location specific TZ values On Sun, Apr 25, 2021 at 07:46:51PM +0200, Sören Tempel wrote: > Hi, > > While debugging a test failure of the calendar application calcurse on > Alpine I noticed that musl does not support TZ values which don't > include area/location information, e.g. TZ=CET [0]. This is contrary to > the documentation from the musl wiki which states the following [1]: > > The zoneinfo file is interpreted as an absolute pathname if it > begins with a slash, a relative pathname if it begins with a > dot, and otherwise is searched in /usr/share/zoneinfo, > /share/zoneinfo, and /etc/zoneinfo. > > Since commit 5c4f11d995cf178b3146cde0734d6988c145f243 musl only consults > the zoneinfo database if the value of the TZ environment variable starts > with a colon or contains a slash [2]. As such, the zoneinfo database is > not consulted for TZ=CET thereby causing musl to not determine DST etc. > correctly for such TZ values. TZ values such as Europe/Kaliningrad are > correctly looked up in the zoneinfo database though. The behavior was the same before that commit except that a leading : was not able to override the behavior and force inspection of a file. > The aforementioned commit claims that this strict check is necessary > since "TZ=name is reserved for POSIX-form" which consists of a mandatory > timezone name (std), an offset, and some more optional information [3]. > **If** TZ values adhering to the POSIX format should not be looked up in > the zoneinfo database, it would be necessary to somehow determine if a > given string adheres to the POSIX timezone format before performing the > lookup. Yes. I suspect we can get by with calling getname with a dummy output array, then checking if the next character is one of +, -, or a digit. If not (in particular, if it's a null character) then we can attempt loading it as a file. It might be worth adding a special exception for "UTC" and "GMT" so that they are always interpreted as "UTC0" and "GMT0" and can't be overridden by a bogus file in the zoneinfo path, for the sake of software that does "TZ=UTC cmd" to avoid any timezone shenanigans. I wonder if we should also check the validity of the string after loading as a file fails, so that if you have TZ=CET but no file named CET, it doesn't get interpreted as if it were CET0 but instead as UTC0. That would avoid bad surprises when the program prints %Z. > The glibc implementation seems to unconditionally consult the zoneinfo > database and falls back to the POSIX format (__tzset_parse_tz) if no > corresponding file was found in the database [4]. Apart from glibc, the > non-POSIX TZ format with TZ= is also supported BSDs, e.g. > OpenBSD [5]. glibc really should not be doing this... Rich