编辑:如果你不进一步否决这个答案,我将不胜感激。
答案是
错误的
,但我宁愿把它作为历史笔记保留下来。虽然pytz接口是否容易出错仍有争议,但它可以做一些有助于dateutil的事情。tz不能这样做,尤其是在过去或未来的夏时制方面。我在一篇文章中诚实地记录了我的经历
"Time zones in Python"
.
如果您使用的是类Unix平台,我建议您避免使用pytz,只查看/usr/share/zoneinfo。dateutil。tz可以利用那里的信息。
下面的代码显示了pytz可以给出的问题。当我第一次发现它时,我很震惊。(有趣的是,百胜在CentOS 7上安装的pytz没有出现这个问题。)
import pytz
import dateutil.tz
from datetime import datetime
print((datetime(2017,2,13,14,29,29, tzinfo=pytz.timezone('Asia/Shanghai'))
- datetime(2017,2,13,14,29,29, tzinfo=pytz.timezone('UTC')))
.total_seconds())
print((datetime(2017,2,13,14,29,29, tzinfo=dateutil.tz.gettz('Asia/Shanghai'))
- datetime(2017,2,13,14,29,29, tzinfo=dateutil.tz.tzutc()))
.total_seconds())
-29160.0
-28800.0
也就是说,pytz创建的时区是真实的当地时间,而不是人们观察的标准当地时间。上海符合+0800,而不是pytz建议的+0806:
pytz.timezone('Asia/Shanghai')
<DstTzInfo 'Asia/Shanghai' LMT+8:06:00 STD>
编辑:
多亏了马克·兰森的评论和否决票,现在我知道我用错了pytz。总之,你不应该通过考试的结果
pytz.timezone(â¦)
到
datetime
,但应通过
约会时间
到它的
localize
方法
尽管他的论点(以及我对没有更仔细地阅读pytz文档的不满),我还是会保留这个答案。我用一种方式回答了这个问题(如何列举受支持的时区,尽管不是用pytz),因为我认为pytz没有提供正确的解决方案。虽然我的想法是错误的,但这个答案仍然提供了一些信息,IMHO,这对对对这个问题感兴趣的人可能有用。皮茨
对的
做事的方式是违反直觉的。见鬼,如果
tzinfo
pytz创建的不应直接用于
约会时间
,它应该是另一种类型。pytz接口设计得很糟糕。
Mark提供的链接表明,很多人,不仅仅是我,被pytz界面误导了。
