[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Bug#1084190: marked as done (breakage due to tzdata System V name removal)

Your message dated Sat, 9 Nov 2024 17:05:13 +0000
with message-id <156c3f53-4a5a-4e81-b5dc-6357f33f9d43@zoho.com>
and subject line Re: Bug#1084190: breakage due to tzdata System V name removal
has caused the Debian Bug report #1084190,
regarding breakage due to tzdata System V name removal
to be marked as done.

This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.

(NB: If you are a system administrator and have no idea what this
message is talking about, this may indicate a serious mail system
misconfiguration somewhere. Please contact owner@bugs.debian.org
immediately.)


-- 
1084190: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1084190
Debian Bug Tracking System
Contact owner@bugs.debian.org with problems
--- Begin Message --- 
Package: tzdata
Version: 2024b-2
Severity: serious
Justification: fails multiple autopkgtests
tadata 2024b changes the meaning of short names such as 'EST' from 'always this offset' to 'alias for a place that currently uses this offset'. This causes several autopkgtest failures:
- pandas and dateparser: use python3-tz and create test reference objects by passing a pytz.timezone directly to datetime.datetime. This has never worked for non-constant time zones, and the python3-tz documentation explicitly warns against it (https://pythonhosted.org/pytz/).
Because this is being done in the test reference and not the actual library, a likely fix is simply to change the test to either use a constant (Etc/GMT-x) timezone or use pytz localize(). I am attempting this on both of them, though my first build of dateparser failed: 
https://salsa.debian.org/science-team/pandas/-/commit/02fd14ebca5bf79f54e65a1a94df23361fa31a84
https://salsa.debian.org/rnpalmer-guest/dateparser
- postgresql-16: is explicitly testing the handling of dates far in the past, which this really does (slightly) change the meaning of. I'm not sure what should be done here.
gnustep-base doesn't display a detailed enough error to say, but plausibly might be a similar problem.
--- End Message ---
--- Begin Message --- Most of these are now fixed, and hence, I agree it no longer makes sense to have a bug open against tzdata itself. 

Please upload the fixed flask-restful.
Fixed: dateparser, pandas, glib, gnustep-base, reposurgeon, g.g.-teambition-rrule-go (described above), g.g.-spf13-cast #1086269, cctz #1084245, g.g.-vulcand-oxy #1084262, neovim #1084888, moment-timezone.js #1084301 
Not fixed but not in testing: lektor #1084286, khal #1084282
Ambiguous - I consider it not fixed but no longer RC: mariadb #1084293
Not fixed, has a fix in Salsa: flask-restful #1084256

--- End Message ---
Reply to: