https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114645
--- Comment #15 from Jonathan Wakely <redi at gcc dot gnu.org> --- (In reply to Hristo Venev from comment #13) > > $TZ allows you to override it per-process (and even change it during the > > lifetime of a process by using setenv and tzset). We don't support that for > > current_zone(). > > /etc/localtime can also change. But not in a racy way. The filesystem serializes those changes so that inspecting the symlink with readlink(3) gives a single race-free answer at any one time. And if the application wants to query current_zone() once and then reuse the result of that query, it can, because the time_zone* is a value held by the application itself. That's an advantage of the std::chrono design which is absent from libc, where the application has very little control over the hidden state that libc maintains for time zone info. > > The intent is to infer an IANA time zone from the /etc/localtime symlink, > > if possible. If the intent was to match libc, it would look at $TZ. I've > > discussed this exact question with the author of that library (which is the > > origin of the std::chrono components too). What I said in comment 8 above > > is paraphrasing what he said. > > Point taken. Still, do you have any explanation for why this behavior was > chosen? Because the environment cannot be accessed safely, and because $TZ was traditionally used for POSIX time zones, which are inferior to the IANA zones in nearly every way (see the "POSIX style time zones" section of https://stackoverflow.com/tags/timezone/info for more details). > > Just do the easy thing yourself. > > The easy thing being to fix all applications that currently use or will ever > use current_zone(). Fun times ahead... Well they should not be assuming current_zone() uses $TZ in the first place - that has never been claimed or documented by any reputable source. You only need to "fix" the ones that were relying on something that was never part of the API.
