From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: by sourceware.org (Postfix, from userid 48) id AD5FC3858CD1; Mon, 8 Apr 2024 20:46:13 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org AD5FC3858CD1 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gcc.gnu.org; s=default; t=1712609173; bh=OMKG6wff2K3RVKUhPSBM2u1zYBX7q1q2lxX4SI1EPzI=; h=From:To:Subject:Date:In-Reply-To:References:From; b=IOd4BhkeNqiq4FSeDV1mCZd3YQzSQVlvS7f6HLQ7JUz2s1aHa0ve4aTjFi31UvYNQ tD37Qg6xAYKZlk/qzVhSAumA1xJUQ2Wa9guVaXWFC/zNHgICoA0nXMXl8fASPYYPAX nEfz0a/fbvp+GCKU6Ecn9seY1ohuSG7Di3n0LWiE= From: "hristo at venev dot name" To: gcc-bugs@gcc.gnu.org Subject: [Bug libstdc++/114645] std::chrono::current_zone ignores $TZ on Linux Date: Mon, 08 Apr 2024 20:46:13 +0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: gcc X-Bugzilla-Component: libstdc++ X-Bugzilla-Version: 13.2.1 X-Bugzilla-Keywords: X-Bugzilla-Severity: normal X-Bugzilla-Who: hristo at venev dot name X-Bugzilla-Status: UNCONFIRMED X-Bugzilla-Resolution: X-Bugzilla-Priority: P3 X-Bugzilla-Assigned-To: unassigned at gcc dot gnu.org X-Bugzilla-Target-Milestone: --- X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: http://gcc.gnu.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 List-Id: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=3D114645 --- Comment #4 from Hristo Venev --- > What does "quite a bit completely useless" mean? current_zone() tells you= what /etc/localtime is set to. So it's as useless as /etc/localtime, no mo= re and no less. What I mean is that in its current state current_zone() is a partial (and incorrect) reimplementation of the logic used by various libcs to determine= the local time zone. By not being an accurate enough implementation it is usele= ss. Given that this partial implementation is correct in some but not all cases= , it is possible that application bugs (e.g. considering that current_zone() is equivalent to libc local time) would go unnoticed, so any use of current_zo= ne() is most likely a bug. In addition to glibc and musl, various other libraries for working with time zones in other languages honor $TZ, for example python's `dateutil` and rus= t's `chrono`. Therefore current_zone() as currently implemented is worse than useless -- = it is a footgun. > Did you read the messages I linked to? Yes. Here are my answers to the points raised in the messages: > No, this is not a good idea. Libstdc++ cannot inspect the environment safely because another thread could be changing it concurrently, which would lead to undefined behaviour. The commented out code was an attempt to support on AIX which is unconventional and has no /etc/localtime symlink. These are just excuses. > In any case, the C++ standard requires that current_zone() refers to the computer's zone, not just the current process' TZ setting: > > "A pointer to the time zone which the computer has set as its local time zone." The people who wrote the standard probably did not consider how various platforms handle default time zones this at all. > is not . The chrono lib is not restricted to only working with a global time zone defined in the standard library, but instead everything works equally well with any chrono::time_zone object, whether that refers to the system zone or not. If you want to use a per-process zone specified by $TZ then you can easily do so, using something like: This is unrelated to the issue. Having current_zone() return the time zone = the user actually wants to use wouldn't magically take away the ability to use other time zones. Having to reimplement libc logic in every application is = not great. > In general, yes, but not here. That would be a glibc-specific feature, so not portable to other targets libstdc++ supports. And in any case, I don't think we want to depend on $TZ. That's not the intended design of the std::chrono API. Interesting point. Is that related to the C++ standard text mentioned in the other message? > Yes, and that's a flaw of , but not a problem with . I don't understand why you consider the ability to override the default time zone using an environment variable to be a flaw. > A C++ program can use **any number** of different time zones. Again, having sane default behavior from current_zone() wouldn't magically prevent other time zones from being used. > There is no > preference given in the API to any particular time zone, unlike the libc > which depends on global state for "the time zone" (singular). The > only time zone that has special treatment in the C++ API is UTC, which is > the default time zone used by std::chrono::zoned_time iff you don't > construct it with a pointer to a specific time zone. But even that can be > changed via chrono::zoned_traits. There **is** a special preference given to the time zone returned by current_zone() -- it is the time zone returned by current_zone(), and most applications using the C++20 time zone library would consider it to be the default "local" time zone.=