https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116110
--- Comment #22 from GCC Commits <cvs-commit at gcc dot gnu.org> --- The releases/gcc-16 branch has been updated by Tomasz Kaminski <[email protected]>: https://gcc.gnu.org/g:10c79f964477c4a20f612a364324545fdc6dca4a commit r16-9430-g10c79f964477c4a20f612a364324545fdc6dca4a Author: Tomasz KamiÅski <[email protected]> Date: Tue Jul 14 16:06:36 2026 +0200 libstdc++: Resolve named-rule UNTIL save adjustment [PR116110] The previous patches for PR 116110 left one case unresolved: a Zone line with a wall-time UNTIL whose RULES field is a named rule set. The save value used to convert the wall UNTIL to UTC depends on which rule of the set was active at the UNTIL instant, but at parse time the rule records have not all been loaded, so the active-rule lookup can't yet be performed. The remaining FIXME in operator>>(istream&, ZoneInfo&) caused zones like Africa/Algiers (around 1977-10-21) to place their zone-line boundary one save-period off from the canonical zic interpretation, producing brief incorrect sys_info windows during DST transitions. This commit defers the save adjustment to the end chrono::reload_tzdb function, after rule data is available. The m_expanded member is replaced with four state _M_state setting: Expanded, and three separte state used for rule based zones: * SaveKnown - m_save contains save value at time m_until * SavePending - m_save is defualted to zero, m_until is correct * UntilPending - as above, but also m_until time need to adjusted The parser set the UntilPending state when it sees a wall-time UNTIL on a named-rule line, and SaveKnown if not UNTIL date is specified. The fixup is performed in bulk for all time_zones in chrono::reload_tzdb using newly calc_save function, guaranteeing proper value of UNTIL during the query. The save at boundary for previous/current ZoneInfo is required to implement proper zone merging, so it is always computed. The active-rule lookup either reuses the existing find_active_rule overload accepting sys_seconds (if UNTIL is not affected by save), or newly introduced overload accepting local_seconds (local time). The local_seconds versions, follows the same logic for finding rule transitions (extracted to find_surrounding_transitions) surrounding the sys_time. The final active rule, is then determined after converting the transition times to local time, including the running save. The test_apia case in 116110.cc had a hardcoded `+11h` workaround for the unfixed bug; with this fix in place the workaround is removed and the value becomes the canonical `+10h`. libstdc++-v3/ChangeLog: PR libstdc++/116110 * src/c++20/tzdb.cc (ZoneInfo::calc_save, ZoneInfo::State): Define. (ZoneInfo::m_expanded): Replaced with m_state. (ZoneInfo::m_pos): Reduce the bit with to 14. (ZoneInfo::m_state): Expands m_expanded with four state enum. (ZoneInfo::ZoneInfo, ZoneInfo::expanded, ZoneInfo::set_abbrev): Replace m_expanded usage with m_state and State::Expanded. (Transitions, find_surrounding_transitions): Extracted from find_active_rule. (find_active_rule): Define overload for local_seconds. Implement both in terms of find_surrounding_transitions. (chrono::reload_tzdb): Calculate save (invoke calc_save) for all infos on all zones. (time_zone::_M_get_sys_info): Define rules as span<const Rules>, and remove the comment. (operator>>(istream&, ZoneInfo&)): Set m_state for UntilPending for UNTIL time using wall time, and SaveKnown for lines without end date. For clarity, set m_save to 0 if daylight is not used. * testsuite/std/time/time_zone/116110.cc (test_apia): Use correct value of the the total offset. * testsuite/std/time/time_zone/pr116110_named.cc: New test. * testsuite/std/time/time_zone/wall_cascade.cc: Add test for last_transition. Reviewed-by: Jonathan Wakely <[email protected]> Co-authored-by: Álvaro Begué <[email protected]> Signed-off-by: Álvaro Begué <[email protected]> Signed-off-by: Tomasz KamiÅski <[email protected]> (cherry picked from commits 020e02fcf281bd24065c8663219a22aba9d0a47d) (4426e08a4fd0d35643d16a14c9e9b81488823a23) (ce285dde2110f453fdbbd89fbb2f85a4d039705d)
