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