[Bug libstdc++/124853] New: std::chrono::time_zone misinterprets a Zone line's first sys_info for zones whose rule set has wall-time rules whose effective firing time depends on a prior rule's save (cascading wall TIME)

alvaro.begue at gmail dot com gcc-bugzilla@gcc.gnu.org
Sat Apr 11 12:59:19 GMT 2026


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

            Bug ID: 124853
           Summary: std::chrono::time_zone misinterprets a Zone line's
                    first sys_info for zones whose rule set has wall-time
                    rules whose effective firing time depends on a prior
                    rule's save (cascading wall TIME)
           Product: gcc
           Version: 16.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: libstdc++
          Assignee: unassigned at gcc dot gnu.org
          Reporter: alvaro.begue at gmail dot com
  Target Milestone: ---

When _M_get_sys_info seeds a Zone line by looking up the active rule
just before info.begin, the seeding code interprets each candidate
rule in isolation against ri.offset() (the line's standard offset
alone), ignoring the running save accumulated by earlier rules in the
same year.

For zones whose rule set has wall-time rules whose effective firing
time depends on a prior rule's save, this gives a wrong answer.

Canonical case: Europe/Paris around 1945.  France's rules

  R Fr 1945 o - Apr 2  2 2 M
  R Fr 1945 o - Sep 16 3 0 -

both use plain wall time.  In Paris's stdoff=1 frame, the September
rule's at_time of 03:00 wall translates to UT Sep 16 02:00 if no
prior save is applied, but to UT Sep 16 00:00 once the running save
of 2h from the April rule is taken into account.  When seeding a
sys_info whose info.begin falls between those two values, the simple
search picks the April rule (save=2 → CEMT, total offset 3h) when
the correct answer is the September rule (save=0 → CET, total offset
1h).


More information about the Gcc-bugs mailing list