[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20210425183841.GU2546@brightrain.aerifal.cx>
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 [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
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.
