https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114645
--- Comment #8 from Jonathan Wakely <redi at gcc dot gnu.org> ---
Yes, if an application assumes that chrono::current_zone matches $TZ, that's a
bug in the application. None of libstdc++, LLVM libc++, MSVC STL or the
date/tz.h reference implementation uses $TZ for chrono::current_zone, and I
don't see how we could do so without breaking the guarantee that
locate_zone(current_zone()->name()) works. The lifetime and ownership of the
pointer returned by current_zone would also be unclear if it didn't return one
of the IANA zones owned by a tzdb object.
The C++ <chrono> library is extensible outside of namespace std, for example:
https://github.com/HowardHinnant/date/blob/master/include/date/ptz.h
(that uses the types and constants from the date namespace defined in date/tz.h
but that can be replaced by namespace date { using namespace std::chrono; })
We could provide something similar as an extension, but it wouldn't be used
automatically by chrono::current_zone, because POSIX time zones (as used by
libc) are not IANA zones.
