F45 Change Proposal: Deprecate Python-dateutil [SelfContained]

Project Discussion Change Proposals
, ,
1

Deprecate Python-dateutil

Wiki

Announced

This is a proposed Change for Fedora Linux.
This document represents a proposed Change. As part of the Changes process, proposals are publicly announced in order to receive community feedback. This proposal will only be implemented if approved by the Fedora Engineering Steering Committee.

Summary :open_book:

Python-dateutil is an extension to the standard Python datetime features, widely used by a lot of other projects. However, upstream is unmaintained and possibly with unaddressed security issues. The plan is to try to continue packaging until feasible, but mark the package as deprecated in Fedora and try to convince other dependent project to switch over from it.

Owner :open_book:

Detailed Description :open_book:

Python-dateutil is an extension to the standard Python datetime features, widely used by a lot of other projects. The following is a list of Fedora packages depending on it:

  • 389-ds-base.src : python3dist(python-dateutil)
  • awscli2.noarch : python3.14dist(python-dateutil) >= 2.1
  • azure-cli.src : python3dist(python-dateutil) >= 2.8
  • barman.src : python3dist(python-dateutil)
  • bidscoin.noarch : python3.14dist(python-dateutil)
  • borgbackup.src : python3dist(python-dateutil)
  • buildbot.src : python3dist(python-dateutil) >= 1.5
  • buildbot-master.noarch : python3.14dist(python-dateutil) >= 1.5
  • calibre.src : python3dist(python-dateutil)
  • ceph-mgr-modules-core.noarch : python3-dateutil
  • conan.noarch : python3.14dist(python-dateutil) >= 2.8
  • copr-backend.noarch : python3-dateutil
  • copr-frontend.noarch : python3dist(python-dateutil)
  • crosswords-puzzle-sets-keesing.noarch : python3dist(python-dateutil)
  • crosswords-puzzle-sets-pzzl.noarch : python3dist(python-dateutil)
  • did.noarch : python3.14dist(python-dateutil)
  • electron-cash.noarch : python3.14dist(python-dateutil)
  • ginga.src : python3dist(python-dateutil) >= 2.8.2
  • gnome-feeds.noarch : python3-dateutil
  • grass.src : python3-dateutil
  • hyperkitty.noarch : python3.14dist(python-dateutil) >= 2
  • jrnl.noarch : (python3.14dist(python-dateutil) < 3~~ with python3.14dist(python-dateutil) >= 2.8)
  • khal.noarch : python3.14dist(python-dateutil)
  • limnoria.noarch : python3-dateutil
  • mailman3.noarch : python3.14dist(python-dateutil) >= 2
  • obs-service-obs_scm-common.noarch : python3-dateutil
  • oci-cli.noarch : python3.14dist(python-dateutil) >= 2.5.3
  • openapi-python-client.noarch : python3.14dist(python-dateutil) >= 2.8.1
  • pcs.noarch : python3-dateutil >= 2.7.0
  • pdd.noarch : python3-dateutil
  • pdfarranger.noarch : python3.14dist(python-dateutil) >= 2.4
  • pgadmin4.src : python3dist(python-dateutil) >= 2
  • picard.src : (python3dist(python-dateutil) >= 2.7 with python3dist(python-dateutil) < 3)
  • python-Mastodon.src : python3dist(python-dateutil)
  • python-OWSLib.src : python3dist(python-dateutil)
  • python-adal.src : (python3dist(python-dateutil) < 3~~ with python3dist(python-dateutil) >= 2.1)
  • python-aniso8601.src : python3-dateutil
  • python-arrow.src : python3dist(python-dateutil) >= 2.7
  • python-azure-multiapi-storage.src : python3dist(python-dateutil)
  • python-azure-storage-common.src : python3dist(python-dateutil)
  • python-beancount.src : python3dist(python-dateutil) >= 2.6
  • python-beanprice.src : python3dist(python-dateutil) >= 2.6
  • python-botocore.src : (python3dist(python-dateutil) < 3~~ with python3dist(python-dateutil) >= 2.1)
  • python-bravado.src : python3dist(python-dateutil)
  • python-bravado-core.src : python3dist(python-dateutil)
  • python-catkin_pkg.src : python3-dateutil
  • python-celery.src : python3dist(python-dateutil) >= 2.8.2
  • python-collada.src : python3dist(python-dateutil)
  • python-cron-converter.src : python3dist(python-dateutil)
  • python-croniter.src : python3dist(python-dateutil)
  • python-dateparser.src : python3dist(python-dateutil) >= 2.7
  • python-datetimerange.src : (python3dist(python-dateutil) < 3~~ with python3dist(python-dateutil) >= 2.4.2)
  • python-deepdiff.src : python3dist(python-dateutil)
  • python-django-extensions.src : python3dist(python-dateutil)
  • python-elasticsearch.src : python3dist(python-dateutil)
  • python-faker.src : python3-dateutil
  • python-feedgen.src : python3dist(python-dateutil)
  • python-freezegun.src : python3dist(python-dateutil) >= 2.7
  • python-ghp-import.src : python3dist(python-dateutil) >= 2.8.1
  • python-github3py.src : python3dist(python-dateutil) >= 2.6
  • python-gnocchiclient.src : python3dist(python-dateutil)
  • python-guessit.src : python3dist(python-dateutil)
  • python-hdmf.src : python3dist(python-dateutil)
  • python-holidays.src : (python3dist(python-dateutil) < 3~~ with python3dist(python-dateutil) >= 2.9^post0)
  • python-hyperkitty.src : python3dist(python-dateutil) >= 2
  • python-hypothesis.src : python3dist(python-dateutil) >= 1.4
  • python-ibm-cloud-sdk-core.src : (python3dist(python-dateutil) < 3~~ with python3dist(python-dateutil) >= 2.9)
  • python-ibm-vpc.src : (python3dist(python-dateutil) < 3~~ with python3dist(python-dateutil) >= 2.5.3)
  • python-icalendar.src : python3dist(python-dateutil)
  • python-influxdb-client.src : python3dist(python-dateutil) >= 2.5.3
  • python-ipyparallel.src : python3dist(python-dateutil) >= 2.1
  • python-javaproperties.src : python3dist(python-dateutil)
  • python-jupyter-client.src : python3dist(python-dateutil) >= 2.8.2
  • python-marshmallow.src : python3-dateutil
  • python-matplotlib.src : python3dist(python-dateutil) >= 2.7
  • python-nihtest.src : python3dist(python-dateutil)
  • python-oci.src : python3dist(python-dateutil) >= 2.5.3
  • python-odata-query.src : (python3dist(python-dateutil) < 3~~ with python3dist(python-dateutil) >= 2.8.1)
  • python-opensearch-py.src : python3dist(python-dateutil)
  • python-orjson.src : (python3dist(python-dateutil) < 3~~ with python3dist(python-dateutil) >= 2)
  • python-oslo-log.src : python3dist(python-dateutil) >= 2.7
  • python-pandas.src : python3dist(python-dateutil) >= 2.8.2
  • python-pelican.src : python3dist(python-dateutil) >= 2.8.2
  • python-pendulum.src : python3dist(python-dateutil) >= 2.6
  • python-pg8000.src : python3dist(python-dateutil) >= 2.8.2
  • python-pikepdf.src : python3dist(python-dateutil) >= 2.8.1
  • python-pskc.src : python3dist(python-dateutil)
  • python-pwntools.src : python3-dateutil
  • python-py-tes.src : python3dist(python-dateutil) >= 2.6.1
  • python-pydantic-core.src : python3dist(python-dateutil)
  • python-pyghmi.src : python3dist(python-dateutil) >= 2.8.1
  • python-pyinfra.src : (python3dist(python-dateutil) < 3~~ with python3dist(python-dateutil) > 2.0)
  • python-pykwalify.src : python3dist(python-dateutil) >= 2.8
  • python-pynwb.src : python3dist(python-dateutil) >= 2.8.2
  • python-rst-linker.src : python3dist(python-dateutil)
  • python-snaptime.src : python3-dateutil
  • python-sphinxcontrib-doxylink.src : (python3dist(python-dateutil) < 3~~ with python3dist(python-dateutil) >= 2.8.2)
  • python-sqlalchemy-utils.src : python3dist(python-dateutil) >= 2.6
  • python-sqlite-utils.src : python3dist(python-dateutil)
  • python-sushy.src : python3dist(python-dateutil) >= 2.7
  • python-tcx2gpx.src : python3dist(python-dateutil)
  • python-tcxparser.src : python3dist(python-dateutil)
  • python-tempora.src : python3dist(python-dateutil)
  • python-time-machine.src : python3dist(python-dateutil)
  • python-typepy.src : python3-dateutil
  • python-vobject.src : python3-dateutil
  • python-webdav4.src : python3dist(python-dateutil) >= 2.8.1
  • python-xnat.src : python3dist(python-dateutil)
  • python-yaql.src : python3dist(python-dateutil) >= 2.4.2
  • python3-Mastodon.noarch : python3.14dist(python-dateutil)
  • python3-OWSLib.noarch : python3.14dist(python-dateutil)
  • python3-barman.noarch : python3.14dist(python-dateutil)
  • python3-django-tastypie.noarch : python3-dateutil
  • python3-dnf-plugins-core.noarch : python3-dateutil
  • python3-gertty.noarch : python3-dateutil
  • python3-ginga+recommended.noarch : python3.14dist(python-dateutil) >= 2.8.2
  • python3-idstools.noarch : python3-dateutil
  • python3-influxdb.noarch : python3.14dist(python-dateutil) >= 2.6
  • python3-ipalib.noarch : python3-dateutil
  • python3-koji.noarch : python3.14dist(python-dateutil)
  • python3-kubernetes.noarch : python3.14dist(python-dateutil) >= 2.5.3
  • python3-lib389.noarch : python3.14dist(python-dateutil)
  • python3-osbs-client.noarch : python3.14dist(python-dateutil)
  • python3-prov.noarch : python3.14dist(python-dateutil) >= 2.2
  • python3-snapm.noarch : python3.14dist(python-dateutil)
  • python3-subscription-manager-rhsm.x86_64 : python3-dateutil
  • python3-visidata.noarch : python3.14dist(python-dateutil)
  • roca-detect.noarch : python3.14dist(python-dateutil)
  • s3cmd.noarch : python3-dateutil
  • salt.noarch : python3.14dist(python-dateutil)
  • samba.src : python3-dateutil
  • snapm.src : python3dist(python-dateutil)
  • starcal.noarch : python3-dateutil
  • stratis-cli.noarch : python3.14dist(python-dateutil)
  • subscription-manager.src : python3-dateutil
  • sugar-toolkit-gtk3.i686 : python3-dateutil
  • syslog-ng.src : python3-dateutil
  • syslog-ng-python-modules.x86_64 : python3-dateutil
  • teampulls.noarch : (python3.14dist(python-dateutil) < 3~~ with python3.14dist(python-dateutil) >= 2.8.2)
  • toot.noarch : (python3.14dist(python-dateutil) < 3~~ with python3.14dist(python-dateutil) >= 2.8.1)
  • visidata.src : python3dist(python-dateutil)
    However, upstream is [Is this project ACTIVELY maintained? ¡ Issue #1404 ¡ dateutil/dateutil ¡ GitHub unmaintained] and possibly with [Vulnerability Disclosure ¡ Issue #1450 ¡ dateutil/dateutil ¡ GitHub unaddressed security issues]. The plan is to try to continue packaging until feasible (it is currently [https://bugzilla.redhat.com/show%20bug.cgi?id=2423882 FTB] with Python 3.15), but mark the package as deprecated in Fedora and try to convince other dependent project to switch over from it.

Feedback :open_book:

Benefit to Fedora :open_book:

Raise attention to unmaintained and possibly unsecure package and try to move away dependent packages from it.

Scope :open_book:

  • Proposal owners:
    Mark package as [Making sure you're not a bot! deprecated].
  • Other developers:
    Optional: get in touch with other dependent packages upstream and raise attention to python-dateutil package status, asking them to move away from it.
  • Release engineering: [Making sure you're not a bot! #Releng issue number]
  • Policies and guidelines: N/A (not needed for this Change)
  • Trademark approval: N/A (not needed for this Change)
  • Alignment with the Fedora Strategy:

Upgrade/compatibility impact :open_book:

While we’ll try to fix the FTB with Python 3.15 to avoid breaking dependent packages, we don’t want to continue patching the project downstream, so we’ll likely orphan the package when the burden gets too high.

Early Testing (Optional) :open_book:

Do you require ‘QA Blueprint’ support? Y/N

How To Test :open_book:

User Experience :open_book:

Dependencies :open_book:

Contingency Plan :open_book:

  • Contingency mechanism: (What to do? Who will do it?) N/A (not a System Wide Change)
  • Contingency deadline: N/A (not a System Wide Change)
  • Blocks release? N/A (not a System Wide Change), Yes/No

Documentation :open_book:

N/A (not a System Wide Change)

Release Notes :open_book:

\n

Last edited by @alking 2026-02-10T17:53:05Z

Last edited by @alking 2026-02-10T17:53:05Z

1 Like
2

How do you feel about the proposal as written?

  • Strongly in favor
  • In favor, with reservations
  • Neutral
  • Opposed, but could be convinced
  • Strongly opposed
0 voters

If you are in favor but have reservations, or are opposed but something could change your mind, please explain in a reply.

We want everyone to be heard, but many posts repeating the same thing actually makes that harder. If you have something new to say, please say it. If, instead, you find someone has already covered what you’d like to express, please simply give that post a :heart: instead of reiterating. You can even do this by email, by replying with the heart emoji or just “+1”. This will make long topics easier to follow.

Please note that this is an advisory “straw poll” meant to gauge sentiment. It isn’t a vote or a scientific survey. See About the Change Proposals category for more about the Change Process and moderation policy.

3

I would like to see advice in the change proposal as how to go about dropping the dependency; e.g. how to port common dateutil usage to standard library features or another library.

2 Likes
4

With this many (~140) packages depending on python-dateutil, this looks like a broad python ecosystem problem to be solved upstream, and beyond the scope of what Fedora maintainers would ordinarily be responsible/expected to get involved in IMHO.

Even if we got package manitainers to file upstream bugs against 140 deps requesting a change, I can’t see even a tiny fraction of such requests being acted upon in a timely manner.

IOW, if the python-dateutil package can’t be rescued from FTBFS in Fedora, then mass orphaning of deps seems inevitable.

It isn’t clear to me that this problem is a fit for the Fedora change process in general.

5

Even if we got package manitainers to file upstream bugs against 140 deps requesting a change, I can’t see even a tiny fraction of such requests being acted upon in a timely manner.

It’s particularly difficult to confidently patch out uses of dateutil because dateutil.parser.parse is a complex and unspecified permissive parser, which “is able to parse most known formats to represent a date and/or time [and] attempts to be forgiving with regards to unlikely input formats, returning a datetime object even for dates which are ambiguous.” For many projects, then, switching to literally any other date parser will be a breaking change, because the format specification is effectively “whatever dateutil.parser.parse will accept.”

6

I’m surprised that this package is an issue.

I see that @churchyard is one of the maintainers and should be able to comment on the state of dateutils.

7

I agree we should encourage our packages to migrate away from this package. I recognize this is not trivial, hence a deprecation, not removal.

2 Likes
8

To clarify, the proposal is to just deprecate the package in Fedora, by the policy this means just that newly added packages cannot depend on it, but it doesn’t immediately harm any existing package.

@yselkowitz this article suggested by @churchyard shows some example dateutil replacement cases, but it’s hard to cover every usage.

As said in the proposal, I’ll start looking at fixing the FTB with Python 3.15 and I hope this turns out to be simple. If not, we’ll soon have a big problem, since a unbuildable dateutil will result in a massive failure in the entire Python ecosystem.

9

BTW, the FTB is caused by sphinx doc generation. The python-dateutil package itself seems to build fine, we could just avoid building docs for the moment, but issues about the project being unmaintained and possibly with unhandled security issues remain.

1 Like
10

The snapm dependency is actually a relic from an earlier iteration of our virt_tests end-to-end testing framework. I already refactored to remove it from the code long ago, but I apparently forgot to delete it from the kickstart templates and BuildRequires: I have filed snapm#960 to fix this upstream (it is trivial/very low risk) and I should be able to get it into Fedora builds within a week or two.

1 Like
11

About the date parsing feature of dateutil, I was looking if it could be replaced by dateparser but I see that dateparser just depends on dateutil… I have raised attention to dateparser maintaners about dateutil maintenance and asked if they’re willing to rewrite their own implementation or bundle and maintain the parser code in their module.

12

This change proposal has now been submitted to FESCo with ticket #3574 for voting.

To find out more, please visit our Changes Policy documentation.

13

To be honest, during last week the maintainer showed some minor activity on the project, but looking at the “importance” of recent changes and at the commit history during recent years, I would only change the word “unmaintained” to “poorly maintained”. I still want to move forward with the proposal and deprecate the package.