On Tue, 6 Oct 2026 at 09:14, Tomasz Kaminski <[email protected]> wrote: > > > > On Tue, Oct 6, 2026 at 10:11 AM Tomasz Kaminski <[email protected]> wrote: >> >> >> >> On Tue, Oct 6, 2026 at 10:03 AM Jonathan Wakely <[email protected]> >> wrote: >>> >>> >>> >>> On Tue, 6 Oct 2026, 08:23 Tomasz Kaminski, <[email protected]> wrote: >>>> >>>> >>>> >>>> On Tue, Oct 6, 2026 at 8:54 AM Tomasz Kaminski <[email protected]> wrote: >>>>> >>>>> >>>>> >>>>> On Mon, Oct 5, 2026 at 11:02 PM Jonathan Wakely <[email protected]> >>>>> wrote: >>>>>> >>>>>> Formatting utc_time can produce a time ending with ":60" for a leap >>>>>> second, so we should also be able to read that back using chrono::parse. >>>>>> >>>>>> We should reject ":60" unless the time really is a leap second, so >>>>>> compare to the list of known leap seconds. Continue to reject ":60" for >>>>>> any time point except utc_time. >>>>>> >>>>>> We need to delay writing to the *abbrev and *offset variables until >>>>>> after we know if the parse is successful, so after handling the >>>>>> _M_is_leap_second flag. >>>>>> >>>>>> libstdc++-v3/ChangeLog: >>>>>> >>>>>> PR libstdc++/126543 >>>>>> * include/bits/chrono_io.h (from_stream): Delay writing abbrev >>>>>> and offset until successful or failed parse has been decided. >>>>>> For utc_time use chrono::get_leap_second_info to check for valid >>>>>> leap seconds. >>>>>> (_Parser::operator()) <R>: Do not accept "60" for minutes. >>>>>> <S>: Accept "60" for seconds. >>>>>> * testsuite/std/time/parse/114279.cc: Use a real leap second as >>>>>> the test input. Check parsing whole seconds as well as >>>>>> fractional seconds. Check that offset isn't written to for >>>>>> failed parse. >>>>>> * testsuite/std/time/parse/126543.cc: New test. >>>>>> --- >>>>>> >>>>>> Tested x86_64-linux. >>>>>> >>>>>> libstdc++-v3/include/bits/chrono_io.h | 74 ++++++++++++------- >>>>>> .../testsuite/std/time/parse/114279.cc | 33 +++++++-- >>>>>> .../testsuite/std/time/parse/126543.cc | 40 ++++++++++ >>>>>> 3 files changed, 112 insertions(+), 35 deletions(-) >>>>>> create mode 100644 libstdc++-v3/testsuite/std/time/parse/126543.cc >>>>>> >>>>>> diff --git a/libstdc++-v3/include/bits/chrono_io.h >>>>>> b/libstdc++-v3/include/bits/chrono_io.h >>>>>> index eec12357fdf7..0d6da0eb1bd7 100644 >>>>>> --- a/libstdc++-v3/include/bits/chrono_io.h >>>>>> +++ b/libstdc++-v3/include/bits/chrono_io.h >>>>>> @@ -3911,24 +3911,27 @@ namespace __detail >>>>>> basic_istream<_CharT, _Traits>& >>>>>> from_stream(basic_istream<_CharT, _Traits>& __is, const _CharT* >>>>>> __fmt, >>>>>> sys_time<_Duration>& __tp, >>>>>> - basic_string<_CharT, _Traits, _Alloc>* __abbrev = >>>>>> nullptr, >>>>>> - minutes* __offset = nullptr) >>>>>> + basic_string<_CharT, _Traits, _Alloc>* __abbrev_p = >>>>>> nullptr, >>>>>> + minutes* __offset_p = nullptr) >>>>>> { >>>>>> + basic_string<_CharT, _Traits, _Alloc> __abbr; >>>>> >>>>> I do not like how we are tripple buffering the __abber now: >>>>> * one string provided by the user provided by >>>>> * one created here >>>>> * one created in operator() >>>> >>>> After re-reading the standard, I do not think it requires that: >>>> > We need to delay writing to the *abbrev and *offset variables until >>>> after we know if the parse succeeded >>>> >>>> The pagraph https://eel.is/c++draft/time.clock.system#nonmembers-6 says: >>>> > If %Z is used and successfully parsed, that value will be assigned to >>>> > *abbrev if abbrev is non-null. >>>> Which for me reads us, if %Z was successfully parsed, the abbrev is >>>> changed, not if the whole thing >>>> was successfully parsed. >>> >>> >>> I don't agree with that interpretation. >>> https://eel.is/c++draft/time.parse#17.sentence-1 says to me that parsing >>> all succeeds or all fails, there is no partial success for one part and >>> failure for another. >> >> The sentence says that failbit is set, it does not mention whether the input >> values are modified. >> That does not contradict my claim that the wording says that abbrev is >> modified as soon as %Z is successfully >> parsed, the failbit (indicating whole parsing failure), may still be set. > > And I think that the ability to pre-allocate/re-use allocation for parsing > many values is more useful than preserving, > input value of *abbrev.
99% of the time the zone abbreviation is 3-6 chars, so uses the SSO buffer and isn't allocated anyway. You could have a date that uses a zone name like "Europe/Warsaw" as the zone abbreviation but it would be unconventional (and that name would still use the SSO buffer anyway). Long zone names like "America/Indiana/Indianapolis" would need to allocate.
