为什么 datetime.utcnow() 返回一个天真的日期时间？ [复制]答案

【问题标题】：Why does datetime.utcnow() return a naive datetime? [duplicate]为什么 datetime.utcnow() 返回一个天真的日期时间？ [复制]
【发布时间】：2018-03-10 17:10:36
【问题描述】：

概念问题。为什么datetime.utcnow() 会返回一个幼稚的日期：

from datetime import datetime
datetime.utcnow()

而不是像这样指定 UTC 时区的时间：

from datetime import datetime, timezone
datetime.utcnow().replace(tzinfo=timezone.utc)

datetime.py 来源表明这是故意的。

@classmethod
def utcnow(cls):
    "Construct a UTC datetime from time.time()."
    t = _time.time()
    return cls.utcfromtimestamp(t)

@classmethod
    def utcfromtimestamp(cls, t):
        """Construct a naive UTC datetime from a POSIX timestamp."""
        return cls._fromtimestamp(t, True, None)

试图了解其背后的思想。谢谢。

编辑：来自linked question here（谢谢），这似乎是 Python 3.2+ 中的首选方法：

from datetime import datetime, timezone
datetime.datetime.now(datetime.timezone.utc)

【问题讨论】：

我的猜测是 UTC 是源自伦敦的通用时间格式，这也是它的默认值。每个人都从“0”开始计数，因此默认为它是有意义的。我明白了这个问题，但如果没有人真正知道它在偏移方面的默认值，它可能会产生更多问题，特别是如果你在不同的平台上运行它。
可能是因为pytz 是第三方。 IMO utc 日期时间对象是唯一可以接受的天真对象，所以更好的问题是为什么 datetime.now() 没有附加本地 tz 信息。
感谢第三方说明 - 没有意识到 timezone.utc 可用。

标签： python

【解决方案1】：

据我所知，这样你可能会伤害自己很多，或者至少我发现这个特定的决定给我带来了无穷无尽的痛苦。我认为问题在于交付的 Python 实际上只支持 UTC 时区，而不支持本地时区。这种想法似乎是很多人都希望对所有事情都使用天真的日期，并跟踪（可能基于它是什么程序）是 UTC 还是本地。因此，涉及时区是您作为程序员必须做出的明确决定，除非您这样做，否则您永远不会得到带有时区的 DateTime。

不幸的是，这个决定与转换 (to posix 时间时，天真的日期时间被视为本地时间的想法相结合会导致很多混乱。我已经讨论了我遇到的一些问题here

【讨论】：