Date: Sun, 25 Apr 2021 14:38:57 -0400 From: Rich Felker <dalias@...c.org> To: Sören Tempel <soeren@...ren-tempel.net> Cc: musl@...ts.openwall.com Subject: Re: 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 . This is contrary to > the documentation from the musl wiki which states the following : > > 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 . 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 . > **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 . Apart from glibc, the > non-POSIX TZ format with TZ=<timezone> is also supported BSDs, e.g. > OpenBSD . glibc really should not be doing this... 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.