Uh oh!
There was an error while loading.Please reload this page.
- Notifications
You must be signed in to change notification settings - Fork33.5k
gh-70647: Better promote how to safely parse yearless dates in datetime.#116179
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 ourterms of service andprivacy statement. We’ll occasionally send you account related emails.
Already on GitHub?Sign in to your account
base:main
Are you sure you want to change the base?
Conversation
…datetime.Every four years people encounter this because it just isn't obvious.This moves the footnote up to a note with a code example.We'd love to change the default year value for datetime but doingthat could have other consequences for existing code. This documentedworkaround *always* works.
Uh oh!
There was an error while loading.Please reload this page.
encukou commentedApr 2, 2024
Perhaps this should be only merged to the backport branches, not main. |
willingc commentedOct 30, 2024
@gpshead Looks like this may need some tidying up if you are still interested. |
StanFromIreland commentedMar 15, 2025
This has already been partially implemented (the smaller note) do we still want to add the larger note since its deprecated anyway? |
| >>>from datetimeimport datetime | ||
| >>>import warnings | ||
| >>>value="2/29" | ||
| >>>with warnings.catch_warnings(): |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others.Learn more.
docs folks: Do we have a way to do this ignoring of the DeprecationWarning in the doctest code without polluting the example code with something I don't want anyone to ever write in their code?
doctest seems to turn the warning into an error which makes it show up and require matching and prevents the actual interesting exception from being raised. (see the earlier failing builds on this PR)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others.Learn more.
Here's a way, I don't know if it's the best way:
..testsetup::# doctest seems to turn the warning into an error which makes it# show up and require matching and prevents the actual interesting# exception from being raised.# Manually apply the `catch_warnings` context managerimportwarningscatch_warnings=warnings.catch_warnings()catch_warnings.__enter__()..testcleanup::catch_warnings.__exit__()..doctest::>>>fromdatetimeimportdatetime>>>importwarnings>>>value="2/29">>>datetime.strptime(value,"%m/%d")Traceback (mostrecentcalllast): ...ValueError:day29mustbeinrange1..28formonth2inyear1900>>>datetime.strptime(f"1904{value}","%Y %m/%d")datetime.datetime(1904,2,29,0,0)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others.Learn more.
Maybe the error is something to do with the C implementation. Depreciation errors don’t show up in the repl unless they are from a C extension resulting in them being forcibly displayed.
Uh oh!
There was an error while loading.Please reload this page.
Every four years people encounter this in part because it just isn't obvious that partial incomplete date parsing is not what
datetime.strptimeis designed for. This moves the footnote up to a more explanatory inline note with a code example.We'd love the default year value for datetime to be different, but changing that could have other consequences for existing code. This documented workaroundalways works.
📚 Documentation preview 📚:https://cpython-previews--116179.org.readthedocs.build/