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

["hristo at venev dot name" <gcc-bugzilla@gcc.gnu.org>]

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

--- Comment #4 from Hristo Venev <hristo at venev dot name> ---
> What does "quite a bit completely useless" mean? current_zone() tells you what /etc/localtime is set to. So it's as useless as /etc/localtime, no more and no less.

What I mean is that in its current state current_zone() is a partial (and
incorrect) reimplementation of the logic used by various libcs to determine the
local time zone. By not being an accurate enough implementation it is useless.

Given that this partial implementation is correct in some but not all cases, it
is possible that application bugs (e.g. considering that current_zone() is
equivalent to libc local time) would go unnoticed, so any use of current_zone()
is most likely a bug.

In addition to glibc and musl, various other libraries for working with time
zones in other languages honor $TZ, for example python's `dateutil` and rust's
`chrono`.

Therefore current_zone() as currently implemented is worse than useless -- it
is a footgun.

> Did you read the messages I linked to?

Yes. Here are my answers to the points raised in the messages:

> No, this is not a good idea. Libstdc++ cannot inspect the environment
safely because another thread could be changing it concurrently, which
would lead to undefined behaviour. The commented out code was an attempt to
support <chrono> on AIX which is unconventional and has no /etc/localtime
symlink.

These are just excuses.

> In any case, the C++ standard requires that current_zone() refers to the
computer's zone, not just the current process' TZ setting:
> > "A pointer to the time zone which the computer has set as its local time
zone."

The people who wrote the standard probably did not consider how various
platforms handle default time zones this at all.

> <chrono> is not <ctime>. The chrono lib is not restricted to only working
with a global time zone defined in the standard library, but instead
everything works equally well with any chrono::time_zone object, whether
that refers to the system zone or not. If you want to use a per-process
zone specified by $TZ then you can easily do so, using something like:

This is unrelated to the issue. Having current_zone() return the time zone the
user actually wants to use wouldn't magically take away the ability to use
other time zones. Having to reimplement libc logic in every application is not
great.

> In general, yes, but not here. That would be a glibc-specific feature, so
not portable to other targets libstdc++ supports. And in any case, I don't
think we want to depend on $TZ. That's not the intended design of the
std::chrono API.

Interesting point. Is that related to the C++ standard text mentioned in the
other message?

> Yes, and that's a flaw of <time.h>, but not a problem with <chrono>.

I don't understand why you consider the ability to override the default time
zone using an environment variable to be a flaw.

> A C++ program can use **any number** of different time zones.

Again, having sane default behavior from current_zone() wouldn't magically
prevent other time zones from being used.

> There is no
> preference given in the API to any particular time zone, unlike the libc
> <time.h> which depends on global state for "the time zone" (singular). The
> only time zone that has special treatment in the C++ API is UTC, which is
> the default time zone used by std::chrono::zoned_time<Dur> iff you don't
> construct it with a pointer to a specific time zone. But even that can be
> changed via chrono::zoned_traits.

There **is** a special preference given to the time zone returned by
current_zone() -- it is the time zone returned by current_zone(), and most
applications using the C++20 time zone library would consider it to be the
default "local" time zone.