pytz localize（）为什么不生成带有tzinfo匹配本地化的tz对象的datetime对象？ | 什么不生成带有tzinfo匹配本地化的tz对象的datetime

本文介绍了pytz localize（）为什么不生成带有tzinfo匹配本地化的tz对象的datetime对象？的处理方法，对大家解决问题具有一定的参考价值，需要的朋友们下面随着小编来一起学习吧！

问题描述

有没有人可以帮助我了解这里的情况？

  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）
结果= tz.localize（dt）
打印repr（result.tzinfo）
＃< DstTzInfo'欧洲/柏林的CET + 1：00：00 STD> 
 assert result.tzinfo == tz，为什么这些时区不同？

我的理解是 localize（） pytz时区对象上的方法将采用朴素的datetime对象，并添加与执行本地化的时区对象匹配的 tzinfo 属性。

很明显，我对时区或pytz处理时区的方式有误解。谁能解释？

解决方案

它们都是相同时区-欧洲/柏林。

 
 
 在打印它们时，输出包括在特定时间点应用的缩写和偏移量。 / p> 
 
 
如果您查看，您将看到：
 ＃区域名称GMTOFF规则格式[UNTIL] 
欧洲/柏林地区0:53:28-LMT 1893 4月
 1:00 C-Eur CE％sT 1945年5月24日2:00 
 1:00苏维埃区CE％ sT 1946 
 1:00德国CE％sT 1980 
 1:00欧盟CE％sT 
  
因此，当时区尚未本地化日期时间时，只是使用第一个条目。
 
 
 似乎pytz不会保留原始本地平均时间偏差之外的额外28秒-但这无关紧要，除非您正在处理1893年4月之前在柏林的约会。
 
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?"
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.
Clearly, there's something I'm misunderstanding about timezones, or about the way that pytz handles timezones. Can anyone explain?
 解决方案 
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.
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.
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对象？的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持！