Re: [musl] Handling of non-location specific TZ values

[Rich Felker <dalias@libc.org>]

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=<timezone> is also supported BSDs, e.g.
> OpenBSD [5].

glibc really should not be doing this...

Rich