Description of problem: 2014.9 is out. Couple issues: - Looks like we'll need to add epoch - 2014.9 < 2012d in rpm land - There are some changes to the the way common_timzones is set - using LazyList/LazySet now. Not sure what these functions do. My simplistic patch would be: -common_timezones = LazyList( - tz for tz in common_timezones if tz in all_timezones) - +common_timezones = [l.split()[2] + for l in open(os.path.join(_tzinfo_dir, "zone.tab")) + if l != "" and l[0] != "#"]\ + + ['GMT', + 'US/Alaska', + 'US/Arizona', + 'US/Central', + 'US/Eastern', + 'US/Hawaii', + 'US/Mountain', + 'US/Pacific', + 'UTC'] +common_timezones.sort() common_timezones_set = LazySet(common_timezones) Is dropping LazyList okay?
I was looking at what it would take to update this as well as setuptools upstream notified me of cornercases with the old versioning scheme and setuptools 8. I'll attach a patch to update for review here. Some notes: * Doesn't look like an Epoch is needed: $ rpmdev-vercmp 0 2012d 1 0 2014.10 1 0:2012d-1 < 0:2014.10-1 * I tried to preserve the LazyList in my patch (but removed the sort because I assume that would defeat the purpose of a LazyList). * My update is untested. I was responding to upstream setuptools' request for an update, I don't currently have any software that uses pytz so I don't have anything to test it with.
Created attachment 970199 [details] Proposed update to pytz Here's a patch to git master to update to 2014.10. I did not remove the old patch because it's easiest to use a graphical diff tool to review the changes in the two versions.
This bug appears to have been reported against 'rawhide' during the Fedora 22 development cycle. Changing version to '22'. More information and reason for this action is here: https://fedoraproject.org/wiki/Fedora_Program_Management/HouseKeeping/Fedora22
Jef - you appear to be non-responsive. I'm going to start the non-responsive maintainer process. Please respond.
This package should really be updated. The included database values are as of 2012! Jef - Please respond. Orion - do you have a plan if Jef doesn't come back to us? Thanks, --scott
Thanks Toshio, I've used your patch.
This package has changed ownership in the Fedora Package Database. Reassigning to the new owner of this component.
What is the status of this bug? I don’t see anything interesting for F22 on http://koji.fedoraproject.org/koji/packageinfo?packageID=3669 Shouldn’t we upgrade ALL maintained distros with it (including EPELs)?
(In reply to Scott K Logan from comment #5) > This package should really be updated. The included database values are as > of 2012! Except we don't use included database at all, right? (instead we use data from tzdata as we should)
I don't know how important it is to update older releases as we use the system timezone database. The python3 package used to ship the included database, but I don't think it used it.
(In reply to Matěj Cepl from comment #9) > Except we don't use included database at all, right? (instead we use data > from tzdata as we should) Very smart. Knowing that, I don't feel bad relaxing a downstream package's version requirements on this package. It would still be a lot cleaner if the package version was updated to more closely resemble the database values behind it. Then such trickery would be unnecessary... --scott
(In reply to Scott K Logan from comment #11) > Very smart. Knowing that, I don't feel bad relaxing a downstream package's > version requirements on this package. It would still be a lot cleaner if the > package version was updated to more closely resemble the database values > behind it. Then such trickery would be unnecessary... I know that, but tzdata updates are VERY frequent and usually sudden (see http://koji.fedoraproject.org/koji/packageinfo?packageID=50; I am actually not sure whether pytz manages to keep up with ALL changes) so I don't think it makes sense to constantly update all language bindings to it.
*** This bug has been marked as a duplicate of bug 1265036 ***