为什么认识时区的datetime的tzinfo不等于时区？

>>> import pytz 
>>> tz = pytz.timezone('America/Chicago') 
>>> dt_naive = datetime(year=2017, month=6, day=6) 
>>> dt_aware = tz.localize(dt_naive) 
>>> dt_aware.tzinfo == tz 
False

这些差异的原因是什么？为什么认识时区的datetime的tzinfo不等于时区？

>>> dt_aware.tzinfo 
<DstTzInfo 'America/Chicago' CDT-1 day, 19:00:00 DST> 
>>> tz 
<DstTzInfo 'America/Chicago' LMT-1 day, 18:09:00 STD>

来源

2017-06-06 wim

@MarkRansom我不同意它是重复的（我实际上已经看到了这个目标）。我在问为什么他们不被认为是平等的，以及如何做到'dt_aware.tzinfo'和'tz'之间的某种有意义的平等比较 - 如果可能的话。 – wim

好的，我现在明白了。你真正的问题是埋葬的。另一个问题回答了唯一明确的问题，“这些差异的原因是什么”。 –

，其确定从pytz的时区是您传递给创建该对象的字符串的关键反映该：'America/Chicago'。该密钥可通过.zone属性获得。

>>> tz = pytz.timezone('America/Chicago') 
>>> dt_naive = datetime(year=2017, month=6, day=6) 
>>> dt_aware = tz.localize(dt_naive) 
>>> dt_aware.tzinfo == tz 
False 
>>> tz.zone 
'America/Chicago' 
>>> dt_aware.tzinfo.zone == tz.zone 
True

来源

2017-06-07 02:36:49

这与使用'str（tz）'相同。我们可以做得更好吗？有许多别名，例如，“America/Chicago”区域和“US/Central”区域在所有实际用途上均应被视为相同。 +1无论如何.. – wim

@wim我没有意识到'str（tz）'与'repr（tz）'不同。由于'zone'是决定对象行为的关键，我认为这是唯一真正代表对象身份的东西。 “美国/芝加哥”和“美国/中环”在某些历史背景下可能有所不同。如果你只是想知道它们是否等同于某个特定时间点，那么你可以用这两个时区定位该时间点，并测试它们是否相等。 –

'US/Central'是'America/Chicago'的别名。它由tzdb [here]中的'Link'条目表示（https://github.com/eggert/tz/blob/2017b/backward#L114）。所以它们在历史背景上是相同的。我认为wim正在寻找一种方法，比较两个不同区域在整套转换规则上的等同性。 –

第一个已经调整到所提供的日期和时间2016-06-06T00:00:00。中央夏令时间（CDT）目前有效。它比UTC晚了5个小时（24:00 - 05:00 = 19:00）。

第二个尚未本地化，所以它会给您提供可用时区数据中的第一个偏移量，它恰好是Local Mean Time (LMT)条目。 You can see this in the tzdata sources here。 LMT比UTC晚5小时50分36秒。该LMT的秒偏移量在pytz某处四舍五入，所以18:09正确（24:00 - 05:51 = 18:09）

来源

2017-06-07 00:04:12

你可以推荐一种方法来对时区实例进行有意义的比较吗？即它们是否具有相同的utcoffset ......那么只是比较它们的“str（tz）”上的相等性呢？ – wim

为什么认识时区的datetime的tzinfo不等于时区？

回答

相关问题