https://gcc.gnu.org/bugzilla/show_bug.cgi?id=125482
--- Comment #3 from Jonathan Wakely <redi at gcc dot gnu.org> ---
Maybe that was the only bug here, as we do reject dates like Nov 31 2026 no
matter how we parse them.
When using %F and %D to parse a whole year_month_day we check it immediately:
if (!year_month_day(__y, __m, __d).ok())
and when using individual fields like %d we check after parsing finishes, to
check that the number of days was valid for the given month and year:
if ((_M_need & _ChronoParts::_Day) != 0)
{
if (__d < day(1) || __d > (__y/__m/last).day())
__err |= ios_base::failbit;
}
For the code above, if the month was not given we use January, which allows up
to day(31), and if the year was not given we use 1972, which allows up to
day(29) for February.
Similarly, if we're parsing a month and a day was also parsed, we check that
the day is valid for that month.
Maybe this can be closed ...
