python-tz 是我错了还是bug [英] python-tz am I wrong or it's a bug

查看:27
本文介绍了python-tz 是我错了还是bug的处理方法,对大家解决问题具有一定的参考价值,需要的朋友们下面随着小编来一起学习吧!

问题描述

似乎有点奇怪,当我想使用 pytz 获取欧洲/巴黎的时区时,当它似乎适用于欧洲/柏林时,它让我进入 PMT 时区而不是 GMT+1.

不清楚?看看这个片段:

#!/usr/bin/python导入操作系统导入日期时间从 pytz.tzfile 导入 build_tzinfobase='/usr/share/zoneinfo/'tz = build_tzinfo('欧洲/巴黎',打开(os.path.join(基地,'欧洲','巴黎'),'rb'))fmt = '%Y-%m-%d %H:%M:%S %Z%z'打印 datetime.datetime(2009, 01, 30, 9, 00, tzinfo=tz).strftime(fmt)tz = build_tzinfo('欧洲/柏林',打开(os.path.join(基地,'欧洲','柏林'),'rb'))打印 datetime.datetime(2009, 01, 30, 9, 00, tzinfo=tz).strftime(fmt)

输出是:

2009-01-30 09:00:00 PMT+00092009-01-30 09:00:00 CET+0100

当真的巴黎应该也是 CET+1 时.

从 datetime.datetime.now(tz) 构造无论如何都会得到正确的结果.

有人有想法吗?

解决方案

文档 说你不能使用 datetime.datetime(..., tzinfo) 就像你在做的:

<块引用>

不幸的是,对于许多时区,使用标准日期时间构造函数的 tzinfo 参数对 pytz 不起作用.

奇怪的是,尽管所有迹象都表明 Europe/Paris 时区是错误的,但当您按照它的建议实际使用 localize 时,它仍然有效:

<预><代码>>>>tz= pytz.timezone('Europe/Paris') # 使用内置的 zoneinfo>>>茨<DstTzInfo '欧洲/巴黎' PMT+0:09:00 STD># 什么?皮埃尔和密克隆时间?>>>datetime.datetime(2010,1,1,12,0,0, tzinfo=tz)datetime.datetime(2010, 1, 1, 12, 0, tzinfo=<DstTzInfo 'Europe/Paris' PMT+0:09:00 STD>) # 坏>>>tz.localize(datetime.datetime(2010,1,1,12,0,0))datetime.datetime(2010, 1, 1, 12, 0, tzinfo=<DstTzInfo 'Europe/Paris' CET+1:00:00 STD>) # OK

请注意,本地化日期时间的 tzinfo 属性引用了一个与创建它的 tz 完全不同的对象,仅共享名称.

为什么会这样对我来说是个谜.理解多个时区名称的城市文件似乎有问题,但是为什么在调用 localize 之前您没有获得城市的默认时区,我不知道.

(老实说,我从不相信 Python 的 datetime 和 tzinfo 的东西.更喜欢使用 int UTC 时间戳.)

It's a bit weird it seems that when I want to get a timezone for Europe/Paris with pytz it gets me to the PMT timezone instead of GMT+1 when it seems to work for Europe/Berlin.

Not clear ? Well look at this snippet :

#!/usr/bin/python
import os
import datetime
from pytz.tzfile import build_tzinfo

base='/usr/share/zoneinfo/'
tz = build_tzinfo('Europe/Paris',
                  open(os.path.join(base,'Europe','Paris'), 'rb'))
fmt = '%Y-%m-%d %H:%M:%S %Z%z'
print datetime.datetime(2009, 01, 30, 9, 00, tzinfo=tz).strftime(fmt)

tz = build_tzinfo('Europe/Berlin',
                  open(os.path.join(base,'Europe','Berlin'), 'rb'))

print datetime.datetime(2009, 01, 30, 9, 00, tzinfo=tz).strftime(fmt)

the output is :

2009-01-30 09:00:00 PMT+0009
2009-01-30 09:00:00 CET+0100

when really paris should be as well CET+1.

Constructing from datetime.datetime.now(tz) would get the thing right no matter what.

Anybody have an idea ?

解决方案

The docs say you can't use datetime.datetime(..., tzinfo) like you're doing:

Unfortunately using the tzinfo argument of the standard datetime constructors does not work with pytz for many timezones.

And curiously, despite all signs that the Europe/Paris timezone is wrong, when you actually use with localize as it recommends, it works nonetheless:

>>> tz= pytz.timezone('Europe/Paris')               # using built-in zoneinfo
>>> tz
<DstTzInfo 'Europe/Paris' PMT+0:09:00 STD>          # what? Pierre et Miquelon Time?
>>> datetime.datetime(2010,1,1,12,0,0, tzinfo=tz)
datetime.datetime(2010, 1, 1, 12, 0, tzinfo=<DstTzInfo 'Europe/Paris' PMT+0:09:00 STD>) # bad
>>> tz.localize(datetime.datetime(2010,1,1,12,0,0))
datetime.datetime(2010, 1, 1, 12, 0, tzinfo=<DstTzInfo 'Europe/Paris' CET+1:00:00 STD>) # OK

Note that the tzinfo property of the localized datetime references a completely different object to the tz it was created from, sharing only the name.

It's a mystery to me why this is happening. It seems to be a problem with city files that understand multiple timezone names, but why you don't get the default timezone for a city until you call localize, I've no idea.

(To be honest I've never trusted Python's datetime and tzinfo stuff. Much prefer working with int UTC timestamps.)

这篇关于python-tz 是我错了还是bug的文章就介绍到这了,希望我们推荐的答案对大家有所帮助,也希望大家多多支持IT屋!

查看全文
登录 关闭
扫码关注1秒登录
发送“验证码”获取 | 15天全站免登陆