PYTZ 'America/Edmonton' offset wrong [dupl

问题:

Possible Duplicate:
Weird timezone issue with pytz

This seems wrong:

>>> import pytz
>>> z1 = timezone('America/Edmonton')
>>> z2 = timezone('US/Mountain')
>>> z1
<DstTzInfo 'America/Edmonton' LMT-1 day, 16:26:00 STD>
>>> z2
<DstTzInfo 'US/Mountain' MST-1 day, 17:00:00 STD>
>>> pytz.VERSION
'2012f'
>>> 

'America/Edmonton' and 'US/Eastern' should be the same time zone (17:00:00 STD). Not to mention 16:26:00 doesn't make any sense.

-- Update --

The above makes sense in context of Jon Skeet's answer. However, things get strange when I do this:

>>> d = datetime.now()
>>> d
datetime.datetime(2012, 10, 9, 15, 21, 41, 644706)

I created a naive date. Since 'America/Edmonton' is my timezone, I try to set that manually:

>>> d2 = d.replace(tzinfo=timezone('America/Edmonton'))
>>> d2
datetime.datetime(2012, 10, 9, 15, 21, 41, 644706, tzinfo=<DstTzInfo 'America/Edmonton' LMT-1 day, 16:26:00 STD>)

This should not have change anything because that is the correct TZ. However:

>>> d2.astimezone(timezone('US/Eastern'))
datetime.datetime(2012, 10, 9, 18, 55, 41, 644706, tzinfo=<DstTzInfo 'US/Eastern' EDT-1 day, 20:00:00 DST>)

This should give me an offset of 2 hours (difference between 'US/Eastern' and 'America/Edmonton') but it gives me 3 hours 26 minutes (which is 2 hours plus one hour 26 minutes :D )

inserting timezone('US/Mountain') produces the correct result in astimezone(). Creating an aware datetime with 'America/Edmonton' will also work correctly.

回答1:

The documentation for pytz explicitly says that creating a datetime directly from a timezone won't work in all cases, and directs you to do the following instead:

d2 = timezone('America/Edmonton').localize(d)

回答2:

Looking at the 2012c TZDB data, here's the rule set for America/Edmonton:

Zone America/Edmonton    -7:33:52 -       LMT   1906 Sep
                         -7:00    Edm     M%sT  1987
                         -7:00    Canada  M%sT

It's not clear to me what date/time the Python output is trying to show you the offset/name for, but I suspect it's something like 1900 - in which case the 16:26:00 makes some sense with the offset of -7:33:52, and it would match the abbreviation, too.

So it's entirely feasible that the time zone data is fine, and it's just choosing to show you an odd date/time as an example. (It makes no sense to me that the string output of a time zone would show a time at all, to be honest...)