On 21.02.23 20:46, Sandro Tosi wrote:
it produces output on stderr, which many tools consider it an error
and fails build.
When raising the severity of a bug to grave I would expect some concrete details
on what exactly is broken instead of a hand-wavy "breaks some stuff".
But anyway let's focus on the issue.
dateutil.zoneinfo really shouldn't be used directly and I don't see any
can you back this quote please? zoneinfo is part of the public API,
and just breaking it (via the removal of the zonefile) and say not to
use it is going in the wrong direction.
https://dateutil.readthedocs.io/en/stable/zoneinfo.html#dateutil.zoneinfo.gettz
has a warning that you shouldn't use it.
For get_zonefile_instance() it only says "using the data provided by the
dateutil package". This implies that the data is outdated most of the time
since it's rarely updated. Unfortunately that's not clearly stated.
Of course it's part of the public API. Unfortunately its design leaves us only
with bad options.
I guess we have two options if we want to change the current behavior:
1) Ship the outdated tzdata tarball even though nothing should really use it.
2) Add a patch to remove the dateutil.zoneinfo fallback.
i think you're missing
3) fix dateutil.zoneinfo to use a system-available zone info file
It wouldn't be fixing it since the sole purpose of this API is to use the
bundled timezone database instead of the potentially absent (from a general POV,
of course the Debian package depends on tzdata) system timezone database.
I'm inclined to just ship the bundled timezone database with the package:
- We wouldn't have to permanently patch the code.
- dateutil consumers that just want accurate timezone information are supposed
to use dateutil.tz.gettz() which already prefers the system database.
- Direct dateutil.zoneinfo users kind of opted into receiving outdated timezone
information.
Felix
