Python时区函数返回关闭9分钟的时区。

Question

由于某些原因，我还无法从以下代码中找出原因：

>>> from pytz import timezone
>>> timezone('America/Chicago')

我得到：

<DstTzInfo 'America/Chicago' LMT-1 day, 18:09:00 STD>

当，我想，我应该得到：

<DstTzInfo 'America/Chicago' LMT-1 day, 18:00:00 STD>

...since我不认为我的时区离UTC有6小时零9分钟的路程。

我已经看过pytz了，但我得承认，我还没有完全搞清楚到底出了什么问题。

我将其他值传递给timezone()函数，它返回的值似乎是正确的。但是，出于某种原因，与我的时区相关的信息是不正确的。

最后，我旁边立方体中的同事确认了函数返回了机器上正确的时区信息。

有人知道为什么我的时区('America/Chicago')会在9分钟前关闭吗？我正在运行使用2015.7安装的pytz版本的pip。谢谢!

Answer 1

除非本地时区有固定的UTC偏移量，否则在不提供特定日期/时间的情况下谈论其特定值是毫无意义的。

如果您提供时间(例如，当前时间)，那么您将看到pytz生成预期的UTC偏移量：

>>> from datetime import datetime
>>> import pytz
>>> datetime.now(pytz.timezone('America/Chicago')).strftime('%Z%z')
'CST-0600'

看见

• 使用pytz的Datetime时区转换
• pytz本地化替换

如果您没有提供特定的日期/时间，那么pytz可能会从给定时区的可用utc偏移量中返回任意utc偏移量。最近的pytz版本返回与最早时间相对应的utc偏移量(通常为LMT)，但您不应该依赖它。你和你的朋友可能会使用不同的pytz版本来解释结果的差异。

Answer 2

基于卡尔·迈耶在谷歌组答案中的回答

造成这种差异的原因是，这不是将与时区无关的日期时间对象转换为时区感知对象的正确方法。

其解释是：

“pytz时区类不代表来自UTC的一个偏移量，它代表的是一个地理区域，在历史过程中，它可能经历了几个UTC偏移。对于给定区域来说，最古老的偏移量，代表时区标准化之前的偏移量(在19世纪末，大多数地方)通常被称为"LMT”(当地平均时间)，而且通常与UTC之间的偏移量是奇数分钟。“

(引用Google组引用的答案)

基本上，你应该做：

from datetime import datetime
import pytz

my_datetime = datetime(2015, 6, 11, 13, 30)
my_tz = pytz.timezone('America/Chicago')    
good_dt = my_tz.localize(my_datetime)

print(good_dt)

out: 2015-06-11 13:30:00-05:00

Answer 3

仅仅因为我的好奇心没有完全得到满足，我最近对这个问题做了更多的调查。

最初，这种差异似乎源于不同版本的pytz。然而，在将我的pytz版本降级为我确认在我的机器上得到的不同结果的版本之后，我发现这并不是问题的根源:即使使用相同版本的pytz，我的机器似乎正在使用基于LMT的UTC偏移量，而其他机器使用的是一台基于CDT或CST的机器。

根据我与@J.F.Sebastian的对话，我认为唯一可能的其他可能性是系统级别的差异。我深入研究了pytz源代码，发现pytz至少从其中获取部分时区信息的文件位于/usr/share/zoneinfo/中。因此，我查看了/usr/share/zoneinfo/America/Chicago文件，尽管它是一个二进制文件，但它的一部分是可读的。在文件的一半过程中，有一个时区列表：LMTCDTCSTESTCWTCPT。如您所见，LMT是列表中的第一个名称，正如@J.F.Sebastian所建议的，这似乎是pytz在我最初的问题中描述的情况中使用的名称。

Ubuntu15.10中的列表就是这样的。但是，在Ubuntu的早期版本(例如，信任和精确)中，我得到的结果是-600而不是-609结果，相同的列表是CDTCSTESTCWTCPT。

我要承认，这来自于大量的盲目探索和半理解，但这似乎是我在不同机器上看到的差异的原因。至于为什么不同版本的zoneinfo文件不同，以及这些差异对Ubuntu意味着什么，我不知道，但我想我会为那些同样好奇的人分享我的发现，并可能从社区获得有洞察力的更正/补充信息。