关于python:请谨慎使用-datetimeutcnow

起步

执行上面代码：

import timefrom datetime import datetime, timezone, timedeltaprint(time.time())print(datetime.utcnow().timestamp())print(datetime.now(timezone.utc).timestamp())print(datetime.now(timezone(timedelta(hours=2))).timestamp())==== output ====1626687759.90810821626658959.9081081626687759.9081081626687759.908108

发现，输入的工夫戳中只有 utcnow() 是不一样，如果比照相差的工夫能发现正好差8小时，而我电脑所在的时区正好是东八区。

起因

正如 utcnow() 文档 所表明的那样，它返回的是 naive time ,Naive datetime 实例被认为为示意本地工夫，因而它的工夫戳会比应用 now(None) 相差的工夫正好是该电脑所在时区。

造成这种诡异解决形式的是有历史起因的，在 Python 2 转 Python 3 的过渡阶段中，datetime.timezone 作为 3.2 版中的新性能被设计了进去，因而有了更为清晰明确的标记日期所在的时区。旧的接口 utcnow() 则保留了原先的解决形式。

新的时区的模型的解决形式与Python 2 存在兼容问题：

==== Python 2 ====>>> from datetime import datetime>>> from dateutil import tz>>> datetime(2021, 5, 1).astimezone(tz.UTC)Traceback (most recent call last):  File "<stdin>", line 1, in <module>ValueError: astimezone() cannot be applied to a naive datetime==== Python 3 ====>>> from datetime import datetime>>> from dateutil import tz>>> datetime(2021, 5, 1).astimezone(tz.UTC)datetime.datetime(2021, 5, 1, 4, 0, tzinfo=tzutc())

总结

综上所述， utcnow() 可能是一个常见的陷阱。我倡议不要再应用 utcnow() 和 utcfromtimestamp() 。