[Bug libstdc++/114645] std::chrono::current_zone ignores $TZ on Linux

["redi at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org>]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114645

--- Comment #15 from Jonathan Wakely <redi at gcc dot gnu.org> ---
(In reply to Hristo Venev from comment #13)
> > $TZ allows you to override it per-process (and even change it during the lifetime of a process by using setenv and tzset). We don't support that for current_zone().
> 
> /etc/localtime can also change.

But not in a racy way. The filesystem serializes those changes so that
inspecting the symlink with readlink(3) gives a single race-free answer at any
one time. And if the application wants to query current_zone() once and then
reuse the result of that query, it can, because the time_zone* is a value held
by the application itself. That's an advantage of the std::chrono design which
is absent from libc, where the application has very little control over the
hidden state that libc maintains for time zone info.

> > The intent is to infer an IANA time zone from the /etc/localtime symlink, if possible. If the intent was to match libc, it would look at $TZ. I've discussed this exact question with the author of that library (which is the origin of the std::chrono components too). What I said in comment 8 above is paraphrasing what he said.
> 
> Point taken. Still, do you have any explanation for why this behavior was
> chosen?

Because the environment cannot be accessed safely, and because $TZ was
traditionally used for POSIX time zones, which are inferior to the IANA zones
in nearly every way (see the "POSIX style time zones" section of
https://stackoverflow.com/tags/timezone/info for more details).

> > Just do the easy thing yourself.
> 
> The easy thing being to fix all applications that currently use or will ever
> use current_zone(). Fun times ahead...

Well they should not be assuming current_zone() uses $TZ in the first place -
that has never been claimed or documented by any reputable source. You only
need to "fix" the ones that were relying on something that was never part of
the API.