aleksis/AlekSIS-App-Kompjuter

Watch

Fork 0

Update dependency python-dateutil to v4 #113

Open

teckids_renovate_bot wants to merge 1 commit from renovate/python-dateutil-4.x into master

teckids_renovate_bot commented

2026-11-01 23:08:55 +01:00

Member

This PR contains the following updates:

Package	Type	Update	Change
python-dateutil	dependencies	major	`^2.8.2` → `^4.0.0`

Release Notes

dateutil/dateutil (python-dateutil)

`v4.0.0`

Compare Source

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 as dateutil.tz.tzname_in_python2. (gh pr #1625)

Bugfixes

parser.isoparse, and the isoparser methods parse_isodate, parse_isotime and parse_tzstr, now require each numeric field to be exactly the expected number of ASCII digits. Strings that were previously accepted, such as 20200728121240 (read as 21:24), 2014- 4-21 and 2_14-04-21, and offsets such as +-1:00, now raise ValueError. tzical applies the same check to TZOFFSETFROM and TZOFFSETTO. Reported by @janos-gonye (gh issue #1074). Fixed by @varun3257 (gh pr #1617).
Fixed an issue where iterating over a cached rrule or rruleset could hang forever if another iterator over the same rule had already completed the cache, for example when a cached rrule was included twice in an rruleset. Reported by @bysiber (gh pr #1455). Fixed by @pganssle (gh pr #1655).
Unpickling a tzutc now gives the dateutil.tz.UTC singleton, and unpickling a tzoffset gives the same object as calling tzoffset(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 as yearday=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 as dateutil.__version__. This mainly affects people building dateutil from 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.

`v3.0.0`

Compare Source

This is the last major version of dateutil that will support any version of Python older than 3.11. The next release will be the 4.x series, which will support Python 3.11 and later. We may release fixes for serious bugs in the 3.0.x series, but there are no plans for new features there.

The biggest change in this release is a rewrite of tz.tzfile, which affects nearly every user of dateutil.tz and changes the UTC offset of nonexistent times (see below). dateutil also now depends on the tzdata package, and no longer ships its own time zone database.

Data updates

dateutil no longer bundles a copy of the IANA time zone database. Time zone data now comes from the system (see dateutil.tz.TZPATH) or, failing that, from the new tzdata dependency, so the data version is whatever version of tzdata is installed. (gh pr #1130)

Features

Rewrote tz.tzfile based on a backport of the zoneinfo module's pure-Python implementation. This adds support for Version 2 and Version 3 tzfile(5) binaries, resolving issues with timestamps beyond 2038 and "slim" format binaries. (gh issues #462, #1059, gh pr #1130)
Added dateutil.tz.TZPATH and dateutil.tz.reset_tzpath to allow for runtime configuration of the IANA time zone data search path. These replace the mutable dateutil.tz.TZPATHS list, which has been removed. (gh pr #1130)
dateutil now depends on the tzdata package, which gettz consults after the search path and before the Windows registry. On Windows this means that names that are both IANA keys and Windows time zone names, such as "UTC", now return a tzfile rather than a tzwin. (gh pr #1130)

Bugfixes

tz.tzfile now follows PEP 495 for times that fall in a gap: with fold=0 it uses the offset from before the transition, and with fold=1 the offset from after it. Previously it always used the offset from after the transition, so for example datetime(2003, 4, 6, 2, 30, tzinfo=tz.gettz("America/New_York")) had a UTC offset of -04:00, where it now has -05:00, the same as with zoneinfo. (gh pr #1130)
tz.tzfile objects for fixed-offset zones, such as tz.gettz("UTC"), now return their offset, DST offset and abbreviation when utcoffset, dst and tzname are called with None, as tz.tzutc, tz.tzoffset and zoneinfo.ZoneInfo do. This means that datetime.time objects with such a zone attached are now aware: time(12, tzinfo=tz.gettz("UTC")).isoformat() is now "12:00:00+00:00" rather than "12:00:00". (gh pr #1130)
tz.tzfile now infers dst() from the standard time on both sides of each DST period, rather than only the one before it, and does so for each transition rather than for each local time type. This fixes dst() for double summer time (e.g. in Europe/London in the 1940s), for half-hour DST (e.g. in Pacific/Rarotonga) and where the standard offset changed at the same time as a DST transition (e.g. in America/Bahia_Banderas in 2010). Against the standard offsets in the tz database source, the only remaining errors are in Europe/Paris in 1944 and 1945. (gh pr #1130)
Fixed rrulestr raising ValueError on experimental X- parameters in an RRULE line (such as GNOME Evolution's X-EVOLUTION-ENDDATE); these are now ignored as RFC 5545 permits. Fixed by @yajo (gh pr #1374)
Enabled pickling and deepcopy of cached rrule and rruleset instances. The cache setting is preserved, and cached results are regenerated on demand without copying locks or generators. Reported by @niccokunzmann (gh issue #1369). Fixed by @Jay1023CN (gh pr #1600).
Fixed relativedelta.__ne__ raising TypeError when comparing against an unsupported type such as None; it now returns True. Reported and fixed by @kevinkt1 (gh issue #1157, gh pr #1158)
Raised the minimum version of six to 1.6, fixing No module named 'six.moves' errors with older versions. Reported by @skytreader (gh issue #1415), fixed by @jdarias3 (gh pr #1424).

Deprecations

Deprecated the dateutil.zoneinfo module. The module now acts as a wrapper around the tzdata package and will be removed in a future version. Users are encouraged to migrate to dateutil.tz.gettz or the standard library's zoneinfo module. dateutil.zoneinfo.rebuild.rebuild no longer does anything, and by default raises RebuildDeprecationWarning as an error; filter the warning to call it as a no-op. (gh pr #1130)
Deprecated passing gettz a relative key that refers to a file outside of every directory on TZPATH, such as "../../etc/localtime". By default this now raises dateutil.tz.DeprecatedTzKeyWarning as an error; filter the warning to keep the old behavior for now, or pass an absolute path instead. (gh pr #1130)

Documentation changes

Added intersphinx to the docs build and cleaned up some broken links. (gh pr #1463)

Misc

Releases are now uploaded to PyPI using trusted publishing, and the built sdist and wheel are tested on all supported platforms before upload. (gh pr #1619, #1622)
Changes to CI, tests and release tooling that do not affect users of the package: gh pr #1417, #1462, #1464, #1465, #1466, #1467, #1468, #1469, #1470, #1499, #1501, #1504, #1576, #1577, #1578, #1581, #1585.

Configuration

📅 Schedule: (UTC)

Branch creation
- At any time (no schedule defined)
Automerge
- At any time (no schedule defined)

🚦 Automerge: Disabled by config. Please merge this manually once you are satisfied.

♻ Rebasing: Whenever PR becomes conflicted, or you tick the rebase/retry checkbox.

🔕 Ignore: Close this PR and you won't be reminded about this update again.

If you want to rebase/retry this PR, check this box

This PR has been generated by Mend Renovate CLI.

This PR contains the following updates: | Package | Type | Update | Change | |---|---|---|---| | [python-dateutil](https://github.com/dateutil/dateutil) | dependencies | major | `^2.8.2` → `^4.0.0` | --- ### Release Notes <details> <summary>dateutil/dateutil (python-dateutil)</summary> ### [`v4.0.0`](https://github.com/dateutil/dateutil/releases/tag/4.0.0) [Compare Source](https://github.com/dateutil/dateutil/compare/3.0.0...4.0.0) `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 as `dateutil.tz.tzname_in_python2`. (gh pr [#1625](https://github.com/dateutil/dateutil/issues/1625)) #### Bugfixes - `parser.isoparse`, and the `isoparser` methods `parse_isodate`, `parse_isotime` and `parse_tzstr`, now require each numeric field to be exactly the expected number of ASCII digits. Strings that were previously accepted, such as `20200728121240` (read as 21:24), `2014- 4-21` and `2_14-04-21`, and offsets such as `+-1:00`, now raise `ValueError`. `tzical` applies the same check to `TZOFFSETFROM` and `TZOFFSETTO`. Reported by [@janos-gonye](https://github.com/janos-gonye) (gh issue [#1074](https://github.com/dateutil/dateutil/issues/1074)). Fixed by [@varun3257](https://github.com/varun3257) (gh pr [#1617](https://github.com/dateutil/dateutil/issues/1617)). - Fixed an issue where iterating over a cached `rrule` or `rruleset` could hang forever if another iterator over the same rule had already completed the cache, for example when a cached `rrule` was included twice in an `rruleset`. Reported by [@bysiber](https://github.com/bysiber) (gh pr [#1455](https://github.com/dateutil/dateutil/issues/1455)). Fixed by [@pganssle](https://github.com/pganssle) (gh pr [#1655](https://github.com/dateutil/dateutil/issues/1655)). - Unpickling a `tzutc` now gives the `dateutil.tz.UTC` singleton, and unpickling a `tzoffset` gives the same object as calling `tzoffset(name, offset)`. Previously unpickling bypassed the singleton-generation logic. Reported and fixed by [@masipcat](https://github.com/masipcat) (gh issue [#1051](https://github.com/dateutil/dateutil/issues/1051), gh pr [#1053](https://github.com/dateutil/dateutil/issues/1053)). - `relativedelta(yearday=366)` now resolves to December 31 in leap years. Previously it gave December 30, the same date as `yearday=365`. Reported and fixed by [@Master-Norna](https://github.com/Master-Norna) (gh pr [#1583](https://github.com/dateutil/dateutil/issues/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 as `dateutil.__version__`. This mainly affects people building `dateutil` from source. (gh pr [#1637](https://github.com/dateutil/dateutil/issues/1637), [#1638](https://github.com/dateutil/dateutil/issues/1638)) - Changes to CI, tests and release tooling that do not affect users of the package: gh pr [#1636](https://github.com/dateutil/dateutil/issues/1636), [#1644](https://github.com/dateutil/dateutil/issues/1644), [#1645](https://github.com/dateutil/dateutil/issues/1645), [#1646](https://github.com/dateutil/dateutil/issues/1646), [#1648](https://github.com/dateutil/dateutil/issues/1648), [#1649](https://github.com/dateutil/dateutil/issues/1649), [#1650](https://github.com/dateutil/dateutil/issues/1650). ### [`v3.0.0`](https://github.com/dateutil/dateutil/releases/tag/3.0.0) [Compare Source](https://github.com/dateutil/dateutil/compare/2.9.0...3.0.0) **This is the last major version of** `dateutil` **that will support any version of Python older than 3.11.** The next release will be the 4.x series, which will support Python 3.11 and later. We may release fixes for serious bugs in the 3.0.x series, but there are no plans for new features there. The biggest change in this release is a rewrite of `tz.tzfile`, which affects nearly every user of `dateutil.tz` and changes the UTC offset of nonexistent times (see below). `dateutil` also now depends on the `tzdata` package, and no longer ships its own time zone database. #### Data updates - `dateutil` no longer bundles a copy of the IANA time zone database. Time zone data now comes from the system (see `dateutil.tz.TZPATH`) or, failing that, from the new `tzdata` dependency, so the data version is whatever version of `tzdata` is installed. (gh pr [#1130](https://github.com/dateutil/dateutil/issues/1130)) #### Features - Rewrote `tz.tzfile` based on a backport of the `zoneinfo` module's pure-Python implementation. This adds support for Version 2 and Version 3 `tzfile(5)` binaries, resolving issues with timestamps beyond 2038 and "slim" format binaries. (gh issues [#462](https://github.com/dateutil/dateutil/issues/462), [#1059](https://github.com/dateutil/dateutil/issues/1059), gh pr [#1130](https://github.com/dateutil/dateutil/issues/1130)) - Added `dateutil.tz.TZPATH` and `dateutil.tz.reset_tzpath` to allow for runtime configuration of the IANA time zone data search path. These replace the mutable `dateutil.tz.TZPATHS` list, which has been removed. (gh pr [#1130](https://github.com/dateutil/dateutil/issues/1130)) - `dateutil` now depends on the `tzdata` package, which `gettz` consults after the search path and before the Windows registry. On Windows this means that names that are both IANA keys and Windows time zone names, such as `"UTC"`, now return a `tzfile` rather than a `tzwin`. (gh pr [#1130](https://github.com/dateutil/dateutil/issues/1130)) #### Bugfixes - `tz.tzfile` now follows PEP 495 for times that fall in a gap: with `fold=0` it uses the offset from before the transition, and with `fold=1` the offset from after it. Previously it always used the offset from after the transition, so for example `datetime(2003, 4, 6, 2, 30, tzinfo=tz.gettz("America/New_York"))` had a UTC offset of -04:00, where it now has -05:00, the same as with `zoneinfo`. (gh pr [#1130](https://github.com/dateutil/dateutil/issues/1130)) - `tz.tzfile` objects for fixed-offset zones, such as `tz.gettz("UTC")`, now return their offset, DST offset and abbreviation when `utcoffset`, `dst` and `tzname` are called with `None`, as `tz.tzutc`, `tz.tzoffset` and `zoneinfo.ZoneInfo` do. This means that `datetime.time` objects with such a zone attached are now aware: `time(12, tzinfo=tz.gettz("UTC")).isoformat()` is now `"12:00:00+00:00"` rather than `"12:00:00"`. (gh pr [#1130](https://github.com/dateutil/dateutil/issues/1130)) - `tz.tzfile` now infers `dst()` from the standard time on both sides of each DST period, rather than only the one before it, and does so for each transition rather than for each local time type. This fixes `dst()` for double summer time (e.g. in `Europe/London` in the 1940s), for half-hour DST (e.g. in `Pacific/Rarotonga`) and where the standard offset changed at the same time as a DST transition (e.g. in `America/Bahia_Banderas` in 2010). Against the standard offsets in the tz database source, the only remaining errors are in `Europe/Paris` in 1944 and 1945. (gh pr [#1130](https://github.com/dateutil/dateutil/issues/1130)) - Fixed `rrulestr` raising `ValueError` on experimental `X-` parameters in an `RRULE` line (such as GNOME Evolution's `X-EVOLUTION-ENDDATE`); these are now ignored as RFC 5545 permits. Fixed by [@yajo](https://github.com/yajo) (gh pr [#1374](https://github.com/dateutil/dateutil/issues/1374)) - Enabled pickling and deepcopy of cached `rrule` and `rruleset` instances. The cache setting is preserved, and cached results are regenerated on demand without copying locks or generators. Reported by [@niccokunzmann](https://github.com/niccokunzmann) (gh issue [#1369](https://github.com/dateutil/dateutil/issues/1369)). Fixed by [@Jay1023CN](https://github.com/Jay1023CN) (gh pr [#1600](https://github.com/dateutil/dateutil/issues/1600)). - Fixed `relativedelta.__ne__` raising `TypeError` when comparing against an unsupported type such as `None`; it now returns `True`. Reported and fixed by [@kevinkt1](https://github.com/kevinkt1) (gh issue [#1157](https://github.com/dateutil/dateutil/issues/1157), gh pr [#1158](https://github.com/dateutil/dateutil/issues/1158)) - Raised the minimum version of `six` to 1.6, fixing `No module named 'six.moves'` errors with older versions. Reported by [@skytreader](https://github.com/skytreader) (gh issue [#1415](https://github.com/dateutil/dateutil/issues/1415)), fixed by [@jdarias3](https://github.com/jdarias3) (gh pr [#1424](https://github.com/dateutil/dateutil/issues/1424)). #### Deprecations - Deprecated the `dateutil.zoneinfo` module. The module now acts as a wrapper around the `tzdata` package and will be removed in a future version. Users are encouraged to migrate to `dateutil.tz.gettz` or the standard library's `zoneinfo` module. `dateutil.zoneinfo.rebuild.rebuild` no longer does anything, and by default raises `RebuildDeprecationWarning` as an error; filter the warning to call it as a no-op. (gh pr [#1130](https://github.com/dateutil/dateutil/issues/1130)) - Deprecated passing `gettz` a relative key that refers to a file outside of every directory on `TZPATH`, such as `"../../etc/localtime"`. By default this now raises `dateutil.tz.DeprecatedTzKeyWarning` as an error; filter the warning to keep the old behavior for now, or pass an absolute path instead. (gh pr [#1130](https://github.com/dateutil/dateutil/issues/1130)) #### Documentation changes - Added intersphinx to the docs build and cleaned up some broken links. (gh pr [#1463](https://github.com/dateutil/dateutil/issues/1463)) #### Misc - Releases are now uploaded to PyPI using trusted publishing, and the built sdist and wheel are tested on all supported platforms before upload. (gh pr [#1619](https://github.com/dateutil/dateutil/issues/1619), [#1622](https://github.com/dateutil/dateutil/issues/1622)) - Changes to CI, tests and release tooling that do not affect users of the package: gh pr [#1417](https://github.com/dateutil/dateutil/issues/1417), [#1462](https://github.com/dateutil/dateutil/issues/1462), [#1464](https://github.com/dateutil/dateutil/issues/1464), [#1465](https://github.com/dateutil/dateutil/issues/1465), [#1466](https://github.com/dateutil/dateutil/issues/1466), [#1467](https://github.com/dateutil/dateutil/issues/1467), [#1468](https://github.com/dateutil/dateutil/issues/1468), [#1469](https://github.com/dateutil/dateutil/issues/1469), [#1470](https://github.com/dateutil/dateutil/issues/1470), [#1499](https://github.com/dateutil/dateutil/issues/1499), [#1501](https://github.com/dateutil/dateutil/issues/1501), [#1504](https://github.com/dateutil/dateutil/issues/1504), [#1576](https://github.com/dateutil/dateutil/issues/1576), [#1577](https://github.com/dateutil/dateutil/issues/1577), [#1578](https://github.com/dateutil/dateutil/issues/1578), [#1581](https://github.com/dateutil/dateutil/issues/1581), [#1585](https://github.com/dateutil/dateutil/issues/1585). </details> --- ### Configuration 📅 **Schedule**: (UTC) - Branch creation - At any time (no schedule defined) - Automerge - At any time (no schedule defined) 🚦 **Automerge**: Disabled by config. Please merge this manually once you are satisfied. ♻ **Rebasing**: Whenever PR becomes conflicted, or you tick the rebase/retry checkbox. 🔕 **Ignore**: Close this PR and you won't be reminded about this update again. --- - [ ] If you want to rebase/retry this PR, check this box --- This PR has been generated by [Mend Renovate CLI](https://github.com/renovatebot/renovate).

teckids_renovate_bot added 1 commit

2026-11-01 23:08:55 +01:00

Update dependency python-dateutil to v4

CI / lock (push) Successful in 44s

Details

CI / lint (push) Successful in 1m6s

Details

CI / build (push) Successful in 1m8s

Details

CI / tests-done (push) Successful in 2s

Details

CI / publish (push) Successful in 8s