Bug report
Bug description:
Bug report
plistlib is documented (in the code) to accept ISO 8601 <date> values where the smaller units are omitted: the date regex _dateParser makes the month, day and time components optional, and the comment above it says "Smaller units may be omitted with a loss of precision".
However, when a <date> value actually omits the day or month, loading fails with a confusing internal TypeError instead of producing a datetime:
>>> import plistlib
>>> plistlib.loads(b'<plist><date>2024-06Z</date></plist>')
Traceback (most recent call last):
...
TypeError: datetime() missing required argument 'day' (pos 3)
>>> plistlib.loads(b'<plist><date>2024Z</date></plist>')
Traceback (most recent call last):
...
TypeError: datetime() missing required argument 'month' (pos 2)
Dates that omit only the time components work fine:
>>> plistlib.loads(b'<plist><date>2024-06-07Z</date></plist>')
datetime.datetime(2024, 6, 7, 0, 0)
>>> plistlib.loads(b'<plist><date>2024-06-07T08Z</date></plist>')
datetime.datetime(2024, 6, 7, 8, 0)
The cause is in Lib/plistlib.py, _date_from_string(): it builds the positional argument list for datetime.datetime() by stopping at the first missing component, so for 2024-06Z it only passes (2024, 6) — fewer than the three required arguments (year, month, day).
The omitted components should default to the start of the period (month=1, day=1, hour/minute/second=0), consistent with how omitted time components already behave and with the documented "loss of precision".
I have a fix with a regression test ready (#151217).
CPython versions tested on:
3.16, CPython main branch
Operating systems tested on:
Linux
Linked PRs
Bug report
Bug description:
Bug report
plistlibis documented (in the code) to accept ISO 8601<date>values where the smaller units are omitted: the date regex_dateParsermakes the month, day and time components optional, and the comment above it says "Smaller units may be omitted with a loss of precision".However, when a
<date>value actually omits the day or month, loading fails with a confusing internalTypeErrorinstead of producing a datetime:Dates that omit only the time components work fine:
The cause is in
Lib/plistlib.py,_date_from_string(): it builds the positional argument list fordatetime.datetime()by stopping at the first missing component, so for2024-06Zit only passes(2024, 6)— fewer than the three required arguments (year, month, day).The omitted components should default to the start of the period (month=1, day=1, hour/minute/second=0), consistent with how omitted time components already behave and with the documented "loss of precision".
I have a fix with a regression test ready (#151217).
CPython versions tested on:
3.16, CPython main branch
Operating systems tested on:
Linux
Linked PRs