https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114645
--- Comment #20 from Jonathan Wakely <redi at gcc dot gnu.org> --- (In reply to Harald van Dijk from comment #18) > (In reply to Jonathan Wakely from comment #16) > > ... incorrectly though? > > Given that you have expressed your view that *any* attempt at using TZ is > inherently incorrect, I am not surprised that you view libc++'s attempt as > incorrect. :) That's not what I mean. I do consider it ill-advised and unsafe to use TZ (since getenv can introduce data races, and I don't think they document potentially concurrent calls to current_zone() and setenv as being unsafe), but libc++ is free to define current_zone() that way if they think that is right for their users. The comment in libc++ notes other problems like the lifetime and ownership one I noted in comment 8, and the inconsistency between "MST" being recognized as an IANA zone but "MST-3" not being. They say "the documentation is unclear" but I disagree, "MST-3" is perfectly valid according to POSIX. And so is TZ="garbage23nonsense", because there is no requirement in POSIX for POSIX-style time zone definitions to have any relation to a real IANA zone. The std and dst names in a POSIX zone are effectively arbitrary. Glibc gets this right: $ date Wed 10 Apr 01:04:17 BST 2024 $ TZ=garbage23nonsense date Tue 9 Apr 02:04:18 nonsense 2024 But quite aside from that, my point in comment 16 is that if they're going to use TZ, I would expect TZ=":Europe/London" to work.
