Warum erzeugt pytz localize() kein Datetime-Objekt mit tzinfo, das mit dem tz-Objekt übereinstimmt, das es lokalisiert hat?

Question

Gibt es jemanden, der mir helfen kann zu verstehen, was hier vor sich geht?

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?" 

Mein war Verständnis, dass die localize() Methode auf einem pytz Zeitzone Objekt wäre ein naives Datetime-Objekt zu nehmen, und fügen Sie eine tzinfo Eigenschaft, die die Zeitzone Objekt entspricht die Lokalisierung durchzuführen. Das scheint in diesem Fall nicht zu geschehen.

Offensichtlich gibt es etwas, was ich über Zeitzonen oder über die Art, wie pytz Zeitzonen behandelt, falsch verstehe. Kann mir jemand erklären?

Answer 1

Sie sind die gleiche Zeitzone - "Europe/Berlin".

Wenn Sie sie drucken, enthält die Ausgabe die Abkürzung und den Offset, der zu diesem bestimmten Zeitpunkt gilt.

Wenn Sie the tz data sources untersuchen, werden Sie sehen:

# 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 wäre es, dass erscheinen, wenn die Zeitzone ein Datetime nicht lokalisiert hat, dann ist es nur der erste Eintrag verwendet.

Es wäre auch, dass pytz scheint nicht die zusätzliche 28 Sekunden aus der ursprünglichen lokalen mittleren Zeitabweichung behalten - aber das macht nichts, wenn Sie mit Terminen in Berlin vor April arbeiten 1893.