[arxhr007]

• Issue: time.fromisoformat() and datetime.fromisoformat() accept a fraction without a decimal mark in the basic format #161017

In parse_hh_mm_ss_ff() a basic-format time (no : separators) steps back one character after each component so the next one can be parsed. After the seconds the loop then ends and the fractional part is parsed from whatever character comes next, without checking for a . or ,. So time.fromisoformat("12304512") returned 12:30:45.12 in the C implementation, while _pydatetime raises ValueError, as the C parser itself does for "12:30:4512".

The fix returns the existing "malformed microsecond separator" error (-4) when the character after the seconds is not a decimal mark and there is no separator.

test_fromisoformat_fails (time) and test_fromisoformat_fails_datetime have new cases. They run for both implementations, and fail without the change for the C one (9 subtests across the _Fast classes).

Checked on a build of main: test_datetime, test_time, test_strptime, test_calendar, test_zoneinfo, test_email and test_json pass. I did not run a refleak build, since the change only adds an early error return before any allocation.

This is similar to gh-158501, which made the C parser reject stray text before an offset.

This was found by comparing the C datetime with _pydatetime using Hypothesis. The change was prepared with the help of an AI coding assistant (Devin CLI).

• Issue: time/datetime.fromisoformat: C accelerator accepts a fractional seconds component with no decimal mark #155175

[python-cla-bot]

All commit authors signed the Contributor License Agreement.

[arxhr007]

Closing as a duplicate of #155177, which makes the same change. Sorry for the noise, I missed it when searching.