https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114645
--- Comment #24 from Jonathan Wakely ---
I have a local patch that would allow applications to define:
namespace __gnu_cxx {
const char* localtime_override() { return getenv("TZ"); }
}
This would make tzdb::current_zone() use the content of
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114645
--- Comment #23 from Jonathan Wakely ---
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
i
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114645
--- Comment #22 from Jonathan Wakely ---
I do still consider it incorrect.
But what I mean re libc++ is that *even ignoring* the general problems with
using TZ, *their implementation* of using TZ isn't even correct. If the
intention is to foll
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114645
--- Comment #21 from Harald van Dijk ---
(In reply to Jonathan Wakely from comment #20)
> (In reply to Harald van Dijk from comment #18)
> > (In reply to Jonathan Wakely from comment #16)
> > > ... incorrectly though?
> >
> > Given that you hav
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114645
--- Comment #20 from Jonathan Wakely ---
(In reply to Harald van Dijk from comment #18)
> (In reply to Jonathan Wakely from comment #16)
> > ... incorrectly though?
>
> Given that you have expressed your view that *any* attempt at using TZ is
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114645
--- Comment #19 from Jonathan Wakely ---
(In reply to Jonathan Wakely from comment #16)
> I would expect TZ=:Europe/London to work according to POSIX,
Well, POSIX says ":characters" is implementation-defined, but for Glibc it
looks up an IANA z
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114645
--- Comment #18 from Harald van Dijk ---
(In reply to Jonathan Wakely from comment #16)
> ... incorrectly though?
Given that you have expressed your view that *any* attempt at using TZ is
inherently incorrect, I am not surprised that you view l
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114645
--- Comment #17 from Jonathan Wakely ---
And "Factory" isn't a valid POSIX zone, so remove that one from the list. So if
I'm reading it correctly, some European zones and the US zones can be used in
$TZ with libc++ but most IANA zones won't work
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114645
--- Comment #16 from Jonathan Wakely ---
(In reply to Harald van Dijk from comment #14)
> (In reply to Jonathan Wakely from comment #8)
> > None of libstdc++, LLVM libc++, MSVC STL or the
> > date/tz.h reference implementation uses $TZ for chron
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114645
--- Comment #15 from Jonathan Wakely ---
(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
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114645
Harald van Dijk changed:
What|Removed |Added
CC||harald at gigawatt dot nl
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114645
--- Comment #13 from Hristo Venev ---
> $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.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114645
--- Comment #12 from Jonathan Wakely ---
(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/dat
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114645
--- Comment #11 from Hristo Venev ---
I never said that reading $TZ is easy, just that not doing it is (in my
opinion) wrong.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114645
--- Comment #10 from Xi Ruoyao ---
> rust's `chrono`
Note that this is really a bad example because of CVE-2020-26235.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114645
--- Comment #9 from Hristo Venev ---
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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114645
--- Comment #8 from Jonathan Wakely ---
Yes, if an application assumes that chrono::current_zone matches $TZ, that's a
bug in the application. None of libstdc++, LLVM libc++, MSVC STL or the
date/tz.h reference implementation uses $TZ for chrono
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114645
--- Comment #7 from Hristo Venev ---
I was actually trying to fix a bug in an existing application that I didn't
write that is using std::chrono::current_zone() under the assumption that it
returns some good approximation of what should be consi
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114645
Jonathan Wakely changed:
What|Removed |Added
Resolution|--- |WONTFIX
Status|UNCONFIRME
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114645
--- Comment #5 from Jonathan Wakely ---
The libc time zone doesn't necessarily correspond to anything in the IANA
database anyway. If you use a POSIX time zone definition like TZ="abc4abd" then
libc will use that to generate a custom time zone a
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114645
--- 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 more
> and no less.
What I mean is that in its current
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114645
--- Comment #3 from Jonathan Wakely ---
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 more and no
less.
Did you read the messages I linked to?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114645
--- Comment #2 from Hristo Venev ---
That makes current_zone() quite a bit completely useless and means that
practically every use of current_zone() is most likely a bug.
Is there some way to get the timezone libc would consider local?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114645
--- Comment #1 from Jonathan Wakely ---
Ignoring $TZ is a feature, not a bug.
See https://gcc.gnu.org/pipermail/libstdc++/2023-May/055928.html and the
replies, including https://gcc.gnu.org/pipermail/libstdc++/2023-May/055933.html
24 matches
Mail list logo