Why doesn't pytz localize() produce a datetime

问题:

Is there anyone who can help me understand what's going on here?

import pytz
from datetime import datetime
tz = pytz.timezone('Europe/Berlin')
print repr(tz)
# <DstTzInfo 'Europe/Berlin' LMT+0:53:00 STD>
dt = datetime(2011, 1, 3, 18, 40)
result = tz.localize(dt)
print repr(result.tzinfo)
# <DstTzInfo 'Europe/Berlin' CET+1:00:00 STD>
assert result.tzinfo == tz, "Why aren't these the same timezone?"

My understanding was that the localize() method on a pytz timezone object would take a naive datetime object, and add a tzinfo property that matches the timezone object performing the localization. That does not appear to be happening in this case.

Clearly, there's something I'm misunderstanding about timezones, or about the way that pytz handles timezones. Can anyone explain?

回答1:

They are the same time zone - "Europe/Berlin".

When you are printing them, the output includes the abbreviation and offset that applies at that particular point in time.

If you examine the tz data sources, you'll see:

# Zone  NAME            GMTOFF   RULES       FORMAT   [UNTIL]
Zone    Europe/Berlin   0:53:28  -           LMT      1893 Apr
                        1:00     C-Eur       CE%sT    1945 May 24 2:00
                        1:00     SovietZone  CE%sT    1946
                        1:00     Germany     CE%sT    1980
                        1:00     EU          CE%sT

So it would appear that when the time zone has not localized a datetime, then it just uses the first entry.

It would also appear that pytz doesn't retain the extra 28 seconds from the original local mean time deviation - but that doesn't matter unless you are working with dates in Berlin before April 1893.