https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114645
--- Comment #12 from Jonathan Wakely <redi at gcc dot gnu.org> --- (In reply to Hristo Venev from comment #9) > I stumbled upon this comment in the library you linked: > > https://github.com/HowardHinnant/date/blob/ > 0e65940a7fbc4ed617a1ee111a60311eccbead9a/include/date/tz.h#L35 > > That comment is wrong in its explanation of the mechanism used to determine > the local time zone on Linux. However, it clearly shows that the intent is > to match the platform's "local time" as closely as reasonably possible. The intent is for current_zone() to be "the time zone which the computer has set as its local time zone", not the time zone that _the process_ has set via TZ. That's /etc/localtime on GNU/Linux and many unixes. Which is what the comment says. $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(). > The implementation also has some comments: > > https://github.com/HowardHinnant/date/blob/ > 0e65940a7fbc4ed617a1ee111a60311eccbead9a/src/tz.cpp#L3936 > > The intent seems to be clear -- apply a lot of heuristics to try to match > what libc would do as closely as possible. 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. > Even on Linux there are no guarantees whatsoever that it is possible to > extract a IANA time zone from /etc/localtime. And so current_zone() can fail. > In fact, the problem is > exactly identical to that with $TZ, if not worse -- $TZ is normally an IANA > time zone name, whereas /etc/localtime is a symlink (but sometimes a > hardlink or a copy) of a file in some OS-specific directory (sometimes, but > not always, /usr/share/zoneinfo) where the name of the file relative to the > base directory is a IANA time zone name. If $TZ is an IANA name then you can just look that name up with locate_zone, it's easy. If $TZ is a POSIX time zone spec, things are more complicated. So the most we could do is handle the easy case, but not in a thread-safe way (because the environment is mutable and not synchronized). So we could support something that is already easy for users to do, by introducing possible data races into the program. That doesn't seem like a good trade off to me. Just do the easy thing yourself.
