【问题标题】:Why do I get the offset 0:53 for timezone Europe/Berlin?为什么我会得到欧洲/柏林时区 0:53 的偏移量?
【发布时间】:2018-10-30 18:47:43
【问题描述】:

示例代码

from datetime import datetime, timezone
import pytz

tzstring = 'Europe/Berlin'
t1 = datetime(2016, 6, 16, 2, 0, tzinfo=pytz.timezone(tzstring))
t2 = datetime(2016, 6, 16, 2, 0, tzinfo=timezone.utc).astimezone(pytz.timezone(tzstring))

观察到

print(t1): 2016-06-16 02:00:00+00:53
print(t2): 2016-06-16 04:00:00+02:00

预期

print(t1): 2016-06-16 04:00:00+02:00  # does not match expectation
print(t2): 2016-06-16 04:00:00+02:00  # matches expectation

问题

谁能给我解释一下?

其他问题:

【问题讨论】:

标签: python python-3.x datetime timezone pytz


【解决方案1】:

我不想说我可以这样解释它,但它记录为不起作用。来自pytz home page

该库仅支持两种构建本地化时间的方法。首先是使用pytz库提供的localize()方法。这用于本地化一个简单的日期时间(没有时区信息的日期时间)

(示例)

构建本地化时间的第二种方法是使用标准astimezone() 方法转换现有本地化时间。

(示例)

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

>>> datetime(2002, 10, 27, 12, 0, 0, tzinfo=amsterdam).strftime(fmt)
'2002-10-27 12:00:00 LMT+0020'

但对于没有夏令时转换的时区是安全的,例如 UTC

我怀疑 pytz 中的时区表示与 datetime 构造函数使用的内容不兼容。

与其追逐确切的细节,我认为接受它不起作用并使用建议的替代方案更实际。

【讨论】:

  • (问题的答案我将这个问题标记为解释它的副本)
  • @SeanBreckenridge 这个答案对你来说可能很清楚,但它肯定不适合我。是的,它在 tz 数据源中。但是为什么会这样呢?
猜你喜欢
  • 2021-04-21
  • 2021-09-16
  • 2019-06-22
  • 2018-03-25
  • 1970-01-01
  • 2021-05-03
  • 2020-05-24
  • 2023-03-12
  • 1970-01-01
相关资源
最近更新 更多