On Sun, 05 Mar 2023 18:50:06 +0100 Arnout Vandecappelle
<arnout.vandecappe...@essensium.com> wrote:
This still fails to address the original issue: an irrelevant warning is
printed when performing a fairly mundane thing (requesting a nonexistent
timezone).
That part could be easily fixed. We can just remove the fallback from dateutil.tz.gettz() to
get_zonefile_instance() since we know that the system database is available.
I repeat: I don't think anyone really wants to use the bundled database.
That's probably true but there are direct users of the dateutil.zoneinfo API which intrinsically
uses the bundled database.
For example within Debian packages:
https://sources.debian.org/src/python-hypothesis/6.67.1-1/hypothesis-python/src/hypothesis/extra/dateutil.py/?hl=56#L56
https://sources.debian.org/src/python-sqlalchemy-utils/0.38.2-2/sqlalchemy_utils/types/timezone.py/?hl=44#L44
These are currently broken. Just silencing the warning will leave them broken.
We could patch the implementation to use the system database but that means deviating from the
upstream behavior and carrying that patch forever.
The API even includes the metadata dictionary that would have to be faked as
well:
https://sources.debian.org/src/python-dateutil/2.8.2-1/dateutil/zoneinfo/__init__.py/#L46
Therefore shipping the bundled zoneinfo tarball seems like the better solution
to me.
The timezone database is clearly DFSG-free. We would have to repackage the upstream tarball to
include the timezone database source though.
Thankfully upstream ships the script to (re-)generate the zoneinfo tarball.
Felix
