我今天遇到了一个有趣的情况。谁能解释为什么 ts1 和 ts2 的偏移量不同? ts1 是一个日期时间对象,可以立即识别时区。 ts2 是一个 datetime 对象,它从 timezone-naive 开始并替换了它的 tzinfo。但是,它们最终会产生不同的偏移量。
>>> from pytz import timezone
>>> EST = timezone('America/New_York')
>>> ts1 = datetime.datetime.now(tz=EST)
>>> ts2 = datetime.datetime.now()
>>> ts2 = ts2.replace(tzinfo=EST)
>>> print ts1
2014-05-16 11:25:16.749748-04:00
>>> print ts2
2014-05-16 11:25:19.581710-05:00
当您调用 ts2.replace(tzinfo=EST)
时,您获得的 tzinfo
对象与您通过 ts1< 获得的对象不匹配
:
>>> ts1
datetime.datetime(2014, 5, 16, 11, 51, 7, 916090, tzinfo=<DstTzInfo 'America/New_York' EDT-1 day, 20:00:00 DST>)
>>> ts2
datetime.datetime(2014, 5, 16, 11, 51, 30, 922692, tzinfo=<DstTzInfo 'America/New_York' LMT-1 day, 19:04:00 STD>)
您最终得到 LMT 而不是 EDT。
pytz
documentation实际上注意到,将 pytz
与标准日期时间对象的 tzinfo
参数一起使用根本不适用于许多时区:
Unfortunately using the tzinfo argument of the standard datetime
constructors ''does not work'' with pytz for many timezones.
>>> datetime(2002, 10, 27, 12, 0, 0, tzinfo=amsterdam).strftime(fmt) '2002-10-27 12:00:00 LMT+0020'
It is safe for timezones without daylight saving transitions though,
such as UTC:
>>> datetime(2002, 10, 27, 12, 0, 0, tzinfo=pytz.utc).strftime(fmt) '2002-10-27 12:00:00 UTC+0000'
我不确定为什么第一个有效;可能是因为当最初使用 tzinfo
对象构造对象时,它实际上不需要转换任何内容。
编辑:
啊,Python documentation请注意,将 datetime.datetime.now()
与 tz
arg 一起使用等同于:
EST.fromutc(datetime.utcnow().replace(tzinfo=EST))
这意味着您正在从 UTC 转换,这对于 pytz
是安全的。这就是第一个起作用的原因。