Repository navigation
gh-158500: Reject trailing characters in date.fromisoformat() - #160737
Open
iamsaugatpandey wants to merge 1 commit into
Open
iamsaugatpandey wants to merge 1 commit into
iamsaugatpandey wants to merge 1 commit into
Conversation
date.fromisoformat() accepts strings of length 7, 8 or 10, but the date
parsers never checked that the whole string was consumed. A 10-character
string without a "-" after the year was parsed as an 8-character basic
format date and its last two characters were dropped, so
date.fromisoformat('2020010112') returned date(2020, 1, 1).
Check that the parser stopped exactly at the end of the date in both the
C and pure-Python implementations.
The pure-Python datetime.fromisoformat() had a similar problem: a date
followed by a single character (such as '2020-01-01T') was accepted
because the empty time part was skipped. Parse the time whenever
something follows the date, as the C implementation does.
iamsaugatpandey
requested review from
StanFromIreland and
pganssle
as code owners
October 26, 2026 21:41
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
date.fromisoformat()accepts strings of length 7, 8 or 10, but neither parser checks that it read the whole string. A 10-character string without a-after the year goes down the basic-format path, which readsYYYYMMDD(orYYYYWwwD) and returns, ignoring the last two characters. So a truncated or mistyped timestamp turns into a plausible but wrong date:With this change, all three raise
ValueError: Invalid isoformat string, asdatetime.fromisoformat()already does for the same input.The fix checks that the parser stopped exactly at the end of the date, in both
parse_isoformat_date()in C and_parse_isoformat_date()in_pydatetime.datetime.fromisoformat()uses the same function for its date part, but there the date always ends at the separator for valid strings. I compared the C module before and after on ~300k fuzzed strings: onlydate.fromisoformat()results changed (all from accepted to rejected), anddatetime.fromisoformat()results did not change at all.While adding the tests I found that the pure-Python
datetime.fromisoformat()has a similar problem. It skipped time parsing whenever the time part was empty, so a date followed by any single character was accepted:The C implementation already rejects these. It now parses the time whenever something follows the date, the same as C. It's the same "didn't consume the whole input" bug, so I kept it here, but I'm happy to split it out if you'd prefer.
Tests are added to
test_fromisoformat_failsandtest_fromisoformat_fails_datetime, so they run against both implementations.