gh-102450: Add ISO-8601 alternative for midnight to fromisoformat() calls.

[TizzySaurus]

Closes #102450.
Closes #124257.

I've updated _datetimemodule.c and _pydatetime.py such that calls to Python's datetime.time.fromisoformat and datetime.datetime.fromisoformat both allow providing the 24:00 ISO-8601 alternative to midnight, but the class constructors themselves do not (as per this comment from @pganssle).

Screenshots of the C code working:

I've also done the same tests for the _pydatetime module and everything appears to be working.

Also updated the datetime tests accordingly, to ensure that datetime.time.fromisoformat("24:00:00.000000") is parsed as datetime.time(0, 0, 0, 0) etc. and the cases that should error (such as datetime.time.fromisoformat("24:30")) do indeed error.

• Issue: datetime library doesn't support valid ISO-8601 alternative for midnight #102450

[bedevere-bot]

Most changes to Python require a NEWS entry.

Please add it using the blurb_it web app or the blurb command-line tool.

[cpython-cla-bot]

All commit authors signed the Contributor License Agreement.

[wookie184]

It seems I don't need to edit the Python code, but just the C?

The PEP that explains it was linked on the issue: #102450 (comment)

Basically, (I believe) you need to implement it in both places but only the C version is used by CPython. If you add tests they should run on both implementations so you can ensure you've done things correctly. You should also be able to import _pydatetime directly to test it manually.

[TizzySaurus]

Thanks @wookie184, that makes sense 😄

I do have a query though: the tests that I added in 311f914 are actually passing (./python.exe -m test -v datetimetester.py), despite me not having implemented the feature into the python code yet. My understanding of PEP399 was that the one file tested both the Python and C implementation, but it seems that datetimetester.py actually only tests the C code? Do I have to write the tests for the Python implementation of the library somewhere else?

EDIT: I've since added the Python implementation, but am still not convinced that the Python implementation is getting tested locally (seems to be here on GitHub though).

[TizzySaurus]

I've also just noticed that the datetime and _pydatetime modules give different errors when specifying an invalid day:

>>> from datetime import datetime as c_datetime
>>> c_datetime.fromisoformat("2023-01-32T24:00:00")
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
ValueError: day is out of range for month

vs

>>> from _pydatetime import datetime as py_datetime
>>> py_datetime.fromisoformat("2023-01-32T24:00:00")
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "/Users/xxx/Documents/personal/cpython/Lib/_pydatetime.py", line 1906, in fromisoformat
    return cls(*(date_components + time_components))
           ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/Users/xxx/Documents/personal/cpython/Lib/_pydatetime.py", line 1717, in __new__
    year, month, day = _check_date_fields(year, month, day)
                       ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/Users/xxx/Documents/personal/cpython/Lib/_pydatetime.py", line 545, in _check_date_fields
    raise ValueError('day must be in 1..%d' % dim, day)
ValueError: ('day must be in 1..31', 32)

Note how _pydatetime's error message specifies the actual day range for that month. Is this something I should add to the C implementation whilst I'm here? Should just be case of swapping PyErr_SetString() with PyErr_Format() -- although not sure how to replicate it being a tuple.

[pganssle]

Note how _pydatetime's error message specifies the actual day range for that month. Is this something I should add to the C implementation whilst I'm here? Should just be case of swapping PyErr_SetString() with PyErr_Format() -- although not sure how to replicate it being a tuple.

We can handle this separately.

[pganssle]

This looks great! Do you want to add yourself to the ACKS file and/or to the patch name, so you get credit? (This is optional)

Also can you rebase against main?

[vstinner]

LGTM. I like how invalid inputs (month 13, non-zero minute, etc.) are checked: it's smart (and keep the code short) :-) I also like tests which seem to cover all cases.

About the feature itself, I trust @pganssle's opinion to decide if we should implement it or not.

[TizzySaurus]

@pganssle Also can you rebase against main?

Think I've done this correctly, so hopefully should be good now 🙂

[vstinner]

Oh nice, the code handles also well the maximum date:

$ ./python
>>> import datetime
>>> datetime.datetime.fromisoformat('9999-12-31T24:00:00')
ValueError: year 10000 is out of range