[Bug libstdc++/109857] New: tzdata 2021a has bad data that cannot be parsed by libstdc++

[Bug libstdc++/109857] New: tzdata 2021a has bad data that cannot be parsed by libstdc++

[redi at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109857

            Bug ID: 109857
           Summary: tzdata 2021a has bad data that cannot be parsed by
                    libstdc++
           Product: gcc
           Version: 13.1.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: libstdc++
          Assignee: unassigned at gcc dot gnu.org
          Reporter: redi at gcc dot gnu.org
  Target Milestone: ---

On debian stable the tzdata.zi file is from version 2021a of the IANA time zone
database and contains this line:

R K 2023 Max - O lastTh 24 0 -

This is invalid, because the fourth field should be "max" not "Max". This
causes libstdc++ to fail to parse the tzdata file and use a UTC-only fallback.

Maybe we should do:

--- a/libstdc++-v3/src/c++20/tzdb.cc
+++ b/libstdc++-v3/src/c++20/tzdb.cc
@@ -345,8 +345,9 @@ namespace std::chrono

       friend istream& operator>>(istream& in, minmax_year&& y)
       {
-       if (ws(in).peek() == 'm') // keywords "minimum" or "maximum"
+       if (unsigned char c = ws(in).peek(); std::tolower(c) == 'm')
          {
+           // keywords "minimum" or "maximum"
            string s;
            in >> s; // extract the rest of the word, but only look at s[1]
            if (s[1] == 'a')


We should also consider ignoring the system tzdata files if the bundled copy
(currently 2023c) is newer. Or at least try using the bundled one if the
parsing the system file fails, as in this case.

[Bug libstdc++/109857] tzdata 2021a has bad data that cannot be parsed by libstdc++

[redi at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109857

Jonathan Wakely <redi at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
   Last reconfirmed|                            |2023-05-14
   Target Milestone|---                         |13.2
     Ever confirmed|0                           |1
             Status|UNCONFIRMED                 |ASSIGNED
           Assignee|unassigned at gcc dot gnu.org      |redi at gcc dot gnu.org

--- Comment #1 from Jonathan Wakely <redi at gcc dot gnu.org> ---
This is the cause of the libstdc++ failures at
https://builder.sourceware.org/buildbot/#/builders/215/builds/3026

[Bug libstdc++/109857] tzdata 2021a has bad data that cannot be parsed by libstdc++

[redi at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109857

--- Comment #2 from Jonathan Wakely <redi at gcc dot gnu.org> ---
(In reply to Jonathan Wakely from comment #0)
> On debian stable the tzdata.zi file is from version 2021a of the IANA time
> zone database and contains this line:
> 
> R K 2023 Max - O lastTh 24 0 -

This is a Debian-specific bug, because they backported the Egypt DST changes:
https://github.com/eggert/tz/commit/dcd8cbed23201416cbd3bbf43f669737693282d7
but not the typo fix:
https://github.com/eggert/tz/commit/af242d11b62584808a66851b8707148bf1ee8d0a

I'm not sure we should bother handling this in libstdc++.

[Bug libstdc++/109857] Debian stable's tzdata 2021a has bad data that cannot be parsed by libstdc++

[redi at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109857

Jonathan Wakely <redi at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           See Also|                            |http://bugs.debian.org/1036
                   |                            |104

--- Comment #3 from Jonathan Wakely <redi at gcc dot gnu.org> ---
FWIW I've confirmed that libstdc++ is able to parse all tzdata.zi files from
2019a to 2023c, using the upstream files.

The Debian bug has been reported to bugs.debian.org.

I'll keep this bug open because I still think this would be a good idea:

(In reply to Jonathan Wakely from comment #0)
> We should also consider ignoring the system tzdata files if the bundled copy
> (currently 2023c) is newer. Or at least try using the bundled one if the
> parsing the system file fails, as in this case.

[Bug libstdc++/109857] Debian stable's tzdata 2021a has bad data that cannot be parsed by libstdc++

[redi at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109857

--- Comment #4 from Jonathan Wakely <redi at gcc dot gnu.org> ---
(In reply to Jonathan Wakely from comment #0)
> We should also consider ignoring the system tzdata files if the bundled copy
> (currently 2023c) is newer.

This would be bad in the Debian case, because they backport changes to the DST
rules from the upstream IANA database, but for Debian stable don't change the
"version" string in tzdata.zi. This means libstdc++ will always think the
system tzdata.zi version "2021a" is older than the bundled "2023c", even though
the system file might actually have newer rules backported from upstream. If we
automatically used the bundled 2023c data we would actually be using older
data.

So let's just go with this:

> Or at least try using the bundled one if the
> parsing the system file fails, as in this case.

i.e. only use the bundled one as a fallback if parsing the on-disk file fails.

[Bug libstdc++/109857] Debian stable's tzdata 2021a has bad data that cannot be parsed by libstdc++

[redi at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109857

--- Comment #5 from Jonathan Wakely <redi at gcc dot gnu.org> ---
(In reply to Jonathan Wakely from comment #4)
> This would be bad in the Debian case, because they backport changes to the
> DST rules from the upstream IANA database, but for Debian stable don't
> change the "version" string in tzdata.zi. This means libstdc++ will always
> think the system tzdata.zi version "2021a" is older than the bundled
> "2023c", even though the system file might actually have newer rules
> backported from upstream. If we automatically used the bundled 2023c data we
> would actually be using older data.

Another consequence of the Debian stable policy is that a long-running C++
process will think it always has the latest tzdb, even if the on-disk tzdata.zi
has actually been updated by apt-get. i.e. std::chrono::reload_tzdb() will
never do anything.

Maybe I should report this as a bug to Debian, and ask them to append some
discriminator to the version string, like "2021a.1", "2021a.2" etc.

[Bug libstdc++/109857] Debian stable's tzdata 2021a has bad data that cannot be parsed by libstdc++

[rguenth at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109857

Richard Biener <rguenth at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
   Target Milestone|13.2                        |13.3

--- Comment #6 from Richard Biener <rguenth at gcc dot gnu.org> ---
GCC 13.2 is being released, retargeting bugs to GCC 13.3.

[Bug libstdc++/109857] Debian stable's tzdata 2021a has bad data that cannot be parsed by libstdc++

[jakub at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109857

Jakub Jelinek <jakub at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
   Target Milestone|13.3                        |13.4

--- Comment #7 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
GCC 13.3 is being released, retargeting bugs to GCC 13.4.