爲什麼認識時區的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不等於時區？

回答

相關問題