Python - calendar.timegm() vs. time.mktime()
我似乎很难理解这一点。
calendar.timegm()和time.mktime()之间有什么区别？
假设我有一个没有连接tzinfo的datetime.datetime，两个不应该给出相同的输出吗？ 难道他们都没有给出纪元和作为参数传递的日期之间的秒数？ 而且由于传递的日期没有tzinfo，那个秒数不一样吗？
1
2
3
4
5
6
7
8
9
| >>> import calendar
>>> import time
>>> import datetime
>>> d = datetime.datetime(2010, 10, 10)
>>> calendar.timegm(d.timetuple())
1286668800
>>> time.mktime(d.timetuple())
1286640000.0
>>> |
-
看到这个问题：stackoverflow.com/questions/15447632/…
time.mktime()假设传递的元组是本地时间，calendar.timegm()假设它是GMT / UTC。 根据解释，元组表示不同的时间，因此函数返回不同的值(自纪元以UTC为基础的秒数)。
值之间的差异应等于本地时区的时区偏移量。
-
哦，我明白了，所以基本上timegm假设我通过了UTC并简单地区分了我通过的和1970.01.01 UTC之间的区别，而mktime首先通过添加我的时区偏移来转换我传递给UTC的内容，并从那里做了timegm做了什么？
-
但是，为什么如果我的datetime的tzinfo为None，那么mktime会进行任何转换吗？它不应该留下它吗？为什么它会假设它在当地时区？
-
@ibz：赋予mktime()的timetuple参数不包含任何时区信息(从不这样做，timetuple中没有时区字段)。因此，该函数必须"猜测"它可能是哪个时区，而mktime()总是假定它是本地时间。这就是函数的行为方式。
-
同时calendar.timegm()将epoch硬编码到1970-01-01UTC(posix epoch)。 time.mktime()可能会使用不同的纪元。来自文档：对于Unix，时代是1970年。要了解时代是什么，请查看gmtime(0)。虽然stdlib的其余部分可能会假设posix时代。
calendar.timegm从UTC时间戳转换，time.mktime从本地时间转换而不是UTC。
8小时的结果差异与您所在位置的时区完全一致。
-
更准确地说，timegm将给定日期解释为UTC，返回时间戳，而mktime将给定日期解释为本地时间，返回时间戳。
-
@Greg：纠正了。误读了文档:)