diff --git a/Doc/library/datetime.rst b/Doc/library/datetime.rst index 16ed3215bc2c1a..060286f152364a 100644 --- a/Doc/library/datetime.rst +++ b/Doc/library/datetime.rst @@ -2640,7 +2640,28 @@ Broadly speaking, ``d.strftime(fmt)`` acts like the :mod:`time` module's For the :meth:`.datetime.strptime` class method, the default value is ``1900-01-01T00:00:00.000``: any components not specified in the format string -will be pulled from the default value. [#]_ +will be pulled from the default value. + +.. note:: + When used to parse partial dates lacking a year, :meth:`~.datetime.strptime` + will raise when encountering February 29 because its default year of 1900 is + *not* a leap year. Always add a default leap year to partial date strings + before parsing. + +.. doctest:: + + >>> from datetime import datetime + >>> import warnings + >>> value = "2/29" + >>> with warnings.catch_warnings(): + ... warnings.simplefilter("ignore") + ... datetime.strptime(value, "%m/%d") + ... + Traceback (most recent call last): + ... + ValueError: day 29 must be in range 1..28 for month 2 in year 1900 + >>> datetime.strptime(f"1904 {value}", "%Y %m/%d") + datetime.datetime(1904, 2, 29, 0, 0) Using ``datetime.strptime(date_string, format)`` is equivalent to:: @@ -2771,7 +2792,7 @@ Notes: include a year in the format. If the value you need to parse lacks a year, append an explicit dummy leap year. Otherwise your code will raise an exception when it encounters leap day because the default year used by the - parser is not a leap year. Users run into this bug every four years... + parser (1900) is not a leap year. Users run into that bug every leap year. .. doctest:: @@ -2798,5 +2819,3 @@ Notes: .. [#] See R. H. van Gent's `guide to the mathematics of the ISO 8601 calendar `_ for a good explanation. - -.. [#] Passing ``datetime.strptime('Feb 29', '%b %d')`` will fail since 1900 is not a leap year.