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.

      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: link
Be 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).