public inbox for gcc-bugs@sourceware.org help / color / mirror / Atom feed
From: "redi at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org> To: gcc-bugs@gcc.gnu.org Subject: [Bug libstdc++/114645] std::chrono::current_zone ignores $TZ on Linux Date: Wed, 10 Apr 2024 01:10:23 +0000 [thread overview] Message-ID: <bug-114645-4-9jzOl1VdOz@http.gcc.gnu.org/bugzilla/> (raw) In-Reply-To: <bug-114645-4@http.gcc.gnu.org/bugzilla/> 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.
prev parent reply other threads:[~2024-04-10 1:10 UTC|newest] Thread overview: 24+ messages / expand[flat|nested] mbox.gz Atom feed top 2024-04-08 19:01 [Bug libstdc++/114645] New: " hristo at venev dot name 2024-04-08 19:27 ` [Bug libstdc++/114645] " redi at gcc dot gnu.org 2024-04-08 20:23 ` hristo at venev dot name 2024-04-08 20:25 ` redi at gcc dot gnu.org 2024-04-08 20:46 ` hristo at venev dot name 2024-04-08 20:48 ` redi at gcc dot gnu.org 2024-04-08 20:51 ` redi at gcc dot gnu.org 2024-04-08 20:56 ` hristo at venev dot name 2024-04-09 9:19 ` redi at gcc dot gnu.org 2024-04-09 9:41 ` hristo at venev dot name 2024-04-09 9:46 ` xry111 at gcc dot gnu.org 2024-04-09 9:49 ` hristo at venev dot name 2024-04-09 16:40 ` redi at gcc dot gnu.org 2024-04-09 17:19 ` hristo at venev dot name 2024-04-09 23:29 ` harald at gigawatt dot nl 2024-04-09 23:29 ` redi at gcc dot gnu.org 2024-04-09 23:43 ` redi at gcc dot gnu.org 2024-04-09 23:47 ` redi at gcc dot gnu.org 2024-04-09 23:50 ` harald at gigawatt dot nl 2024-04-09 23:57 ` redi at gcc dot gnu.org 2024-04-10 0:07 ` redi at gcc dot gnu.org 2024-04-10 0:26 ` harald at gigawatt dot nl 2024-04-10 0:57 ` redi at gcc dot gnu.org 2024-04-10 1:10 ` redi at gcc dot gnu.org [this message]
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to=bug-114645-4-9jzOl1VdOz@http.gcc.gnu.org/bugzilla/ \ --to=gcc-bugzilla@gcc.gnu.org \ --cc=gcc-bugs@gcc.gnu.org \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: linkBe sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).