dateutil 4.0 requires Python 3.11 or later and no longer depends on six. Apart from that, the changes in this release are bug fixes, but note that isoparse is now stricter about the numeric fields it accepts (see below).
Deprecations
- Dropped support for Python versions older than 3.11 and removed the dependency on
six, along with Python 2 compatibility helpers that were never part of the public API, such asdateutil.tz.tzname_in_python2. (gh pr #1625)
Bugfixes
parser.isoparse, and theisoparsermethodsparse_isodate,parse_isotimeandparse_tzstr, now require each numeric field to be exactly the expected number of ASCII digits. Strings that were previously accepted, such as20200728121240(read as 21:24),2014- 4-21and2_14-04-21, and offsets such as+-1:00, now raiseValueError.tzicalapplies the same check toTZOFFSETFROMandTZOFFSETTO. Reported by @janos-gonye (gh issue #1074). Fixed by @varun3257 (gh pr #1617).- Fixed an issue where iterating over a cached
rruleorrrulesetcould hang forever if another iterator over the same rule had already completed the cache, for example when a cachedrrulewas included twice in anrruleset. Reported by @bysiber (gh pr #1455). Fixed by @pganssle (gh pr #1655). - Unpickling a
tzutcnow gives thedateutil.tz.UTCsingleton, and unpickling atzoffsetgives the same object as callingtzoffset(name, offset). Previously unpickling bypassed the singleton-generation logic. Reported and fixed by @masipcat (gh issue #1051, gh pr #1053). relativedelta(yearday=366)now resolves to December 31 in leap years. Previously it gave December 30, the same date asyearday=365. Reported and fixed by @Master-Norna (gh pr #1583).
Misc
- The build backend is now Hatchling, and the package metadata is in
pyproject.toml. Versions are still derived from Git tags and exposed asdateutil.__version__. This mainly affects people buildingdateutilfrom source. (gh pr #1637, #1638) - Changes to CI, tests and release tooling that do not affect users of the package: gh pr #1636, #1644, #1645, #1646, #1648, #1649, #1650.