Followup-For: Bug #1003044
On Tue, 21 Feb 2023 14:46:01 -0500, morph wrote:
> On Sun, Jan 29, 2023 at 9:45 AM Felix Geyer <fge...@debian.org> wrote:
> > How exactly does this break matplotlib?
> it produces output on stderr, which many tools consider it an error
> and fails build.
On Fri, 3 Mar 2023 15:05:03 -0500, morph wrote:
> Either we reintroduce the timezone file (that may not be a good idea)
> or translate these deprecated APIs into the recommended one, or we do
> something else entirely, it's up for debate.
On Sun, 05 Mar 2023 15:37:43 +0100, Arnout wrote:
> AFAICS, the API is not deprecated. It is also not really broken. Is just
> that if you ask explicitly for the bundled database, you get an empty
> database. Currently, you get an empty database and a warning is printed; my
> patch just removes that warning.
This isn't ideal, but if we're not comfortable bundling the database or coding
a compatibility interface... perhaps helping people to fix the warnings in
their own environments (re: stderr) could be a next-best-option?
We could extend the warning messaging; something like:
"An error occurred while attempting to read {0}.\n"
+
"To resolve this warning, please ensure that a dateutil-compatible timezone "
"data tarball exists and is readable at {1}.\n"
+
"Note: an empty tarball is considered valid and will silence this warning, "
"but you should check the code path(s) that emitted these warnings before "
"supplying that, since it will not provide any timezone information."
The intended effect of that would be:
* Do not hide that a failure occurred
* Provide more explanation about what went wrong
* Provide solution options to sysadmin (although sometimes user != sysadmin)
* Attempt to use messaging that python-dateutil upstream could merge
