https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114645
--- Comment #23 from Jonathan Wakely <redi at gcc dot gnu.org> --- Re https://github.com/cplusplus/draft/issues/6922 It can't possibly mean that the returned time zone *needs* to be the same as the C library, because that's impossible in general, because the C library isn't required to use IANA zones at all. See my TZ=garbage23nonsense example. There is no way to match that with std::chrono::time_zone without pointer lifetime issues and inconsistencies like returning a time_zone that isn't in the tzdb. And if the C++ standard intended to require that TZ is respected on POSIX systems, then it would say so. The absence of any requirement means it's not required. TZ is not mentioned in the standard at all. The standard probably isn't going to say it *must not* be used, because it's not in the business of listing (or forbidding) possible vendor extensions. There might be systems where a TZ environment var is the only way the time zone can be set, and it always is an IANA zone. But I don't believe any of the targets libstdc++ supports fit into that category.
