Description of problem: It's necessary to update pytz to more recent version, current 2006p is ancient by tzdata standards. To avoid having to rebase every time Olson database changes, pytz should use tzdata files instead of its own. It might be possible to even not ship pytz own data, and simply use tzdata always. Version-Release number of selected component (if applicable): pytz-2006p-3.fc9.noarch How reproducible: Always. Steps to Reproduce: $ rpm -ql tzdata | grep Salta /usr/share/zoneinfo/America/Argentina/Salta /usr/share/zoneinfo/posix/America/Argentina/Salta /usr/share/zoneinfo/right/America/Argentina/Salta $ python -c 'import pytz; pytz.timezone("America/Argentina/Salta")' Traceback (most recent call last): File "<string>", line 1, in <module> File "/usr/lib/python2.5/site-packages/pytz/__init__.py", line 71, in timezone raise KeyError, zone KeyError: 'America/Argentina/Salta' Actual results: New zones are not available, the existing ones are presumably not current. Expected results: pytz is kept in sync with tzdata. Additional info: I've had a chat with pytz maintainer, and he told me that new versions of pytz already have a support in place that makes it possible to not use pytz own zoneinfo data, and supply system-wide instead. Debian are reportedly doing just that. It would be a very desirable feature to have in Fedora, too.
*** Bug 471011 has been marked as a duplicate of this bug. ***
Just a quick note that Debian's patch is a good start but has some issues as described here: https://bugs.launchpad.net/pytz/+bug/207604/ I also see the issue that the Olson version is hard-coded in the file. Probably this should be read dynamically.
Created attachment 340146 [details] Ubuntu's python-tz patch from Jaunty (against 2008i) I extracted the patch from http://packages.ubuntu.com/jaunty/python-tz. License needs to be checked.
Ah, I just found out that this was fixed in bug 471014 already due to duplicated reports :-) *** This bug has been marked as a duplicate of bug 471014 ***