有没有人可以帮助我了解这里发生了什么?
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?"
我的理解是，pytz 时区对象上的 localize() 方法将采用一个简单的 datetime 对象，并添加一个与执行时区对象相匹配的 tzinfo 属性本土化.在这种情况下似乎没有发生这种情况.
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.
显然，我对时区或 pytz 处理时区的方式有一些误解.谁能解释一下?
Clearly, there's something I'm misunderstanding about timezones, or about the way that pytz handles timezones. Can anyone explain?
它们是相同的时区 - "Europe/Berlin".
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.
如果您检查 tz 数据源，您会发现会看到:
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.
看起来 pytz 并没有保留原始本地平均时间偏差的额外 28 秒 - 但这并不重要，除非您使用的是 1893 年 4 月之前在柏林的日期.
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.
这篇关于为什么 pytz localize() 不生成一个 tzinfo 与本地化它的 tz 对象匹配的 datetime 对象?的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持跟版网！