-
-
Notifications
You must be signed in to change notification settings - Fork 590
String date format check allows unexpected formats with Python 3.11 and later #1056
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Comments
Thanks! The proposed change sounds reasonable (to use a regex) -- but the first step as it sounds like you found is to add some (failing) test cases upstream to the test suite. Any chance you're up for doing so? |
I might have some spare time during the weekend, but no promises... |
Some progress: after some Also spotted that also Hopefully having some more time in few days. |
Python 3.11 and later allow additional ISO8601 formats in `datetime` module ISO8601 parsing. These new formats are not RFC3339 section 5.6 compliant. Especially `datetime.date.fromisoformat()` now allows strings like: * `20230328` (2023-03-28) * `2022W527` (2023-01-01) * `2023-W01` (2023-01-02) * `2023-W13-2` (2023-03-28) Fix by doing a regular expression check before passing the value to `datetime` module. This made the original `.isascii()` check unnecessary. See: * https://docs.python.org/3/whatsnew/3.11.html#datetime * python/cpython@1303f8c927 * https://docs.python.org/3.11/library/datetime.html#datetime.date.fromisoformat * https://www.rfc-editor.org/rfc/rfc3339#section-5.6 Tests covering the invalid values to be sent to json-schema-org/JSON-Schema-Test-Suite Fixes python-jsonschema#1056.
Python 3.11 and later allow additional ISO8601 formats in `datetime` module ISO8601 parsing. These formats are not RFC3339 section 5.6 compliant. Especially `datetime.date.fromisoformat()` now allows strings like: * `20230328` (2023-03-28) * `2022W527` (2023-01-01) * `2023-W01` (2023-01-02) * `2023-W13-2` (2023-03-28) Fix by doing a regular expression check before passing the value to `datetime` module. This made the original `.isascii()` check unnecessary. See: * https://docs.python.org/3/whatsnew/3.11.html#datetime * python/cpython@1303f8c927 * https://docs.python.org/3.11/library/datetime.html#datetime.date.fromisoformat * https://www.rfc-editor.org/rfc/rfc3339#section-5.6 Tests covering the invalid values to be sent to json-schema-org/JSON-Schema-Test-Suite Fixes python-jsonschema#1056.
Python 3.11 and later allow additional ISO8601 formats in `datetime` module ISO8601 parsing. These formats are not RFC3339 section 5.6 compliant. Especially `datetime.date.fromisoformat()` now allows strings like: * `20230328` (2023-03-28) * `2022W527` (2023-01-01) * `2023-W01` (2023-01-02) * `2023-W13-2` (2023-03-28) Fix by doing a regular expression check before passing the value to `datetime` module. This made the original `.isascii()` check unnecessary. See: * https://docs.python.org/3/whatsnew/3.11.html#datetime * python/cpython@1303f8c927 * https://docs.python.org/3.11/library/datetime.html#datetime.date.fromisoformat * https://www.rfc-editor.org/rfc/rfc3339#section-5.6 Tests covering the invalid values to be sent to json-schema-org/JSON-Schema-Test-Suite Fixes python-jsonschema#1056.
Looks like
date
format check usesdatetime.date.fromisoformat()
. The behavior changed in Python 3.11, allowing e.g.2023-W01
and20230315
style strings.Running this with Python 3.11.x and having
jsonschema[format]
installed:results in this:
Quickly looking at the code it feels like a regular expression match
^\d{4}-\d{2}-\d{2}$
and keeping thefromisoformat()
call would be the easiest fix.See
The text was updated successfully, but these errors were encountered: