Python 是否存在time.gmtime（）的反函数，该函数将UTC元组解析为从纪元开始的秒数？

python的时间模块似乎有点随意。例如，这里有一个docstring中的方法列表：

time() -- return current time in seconds since the Epoch as a float
clock() -- return CPU time since process start as a float
sleep() -- delay for a number of seconds given as a float
gmtime() -- convert seconds since Epoch to UTC tuple
localtime() -- convert seconds since Epoch to local time tuple
asctime() -- convert time tuple to string
ctime() -- convert time in seconds to string
mktime() -- convert local time tuple to seconds since Epoch
strftime() -- convert time tuple to string according to format specification
strptime() -- parse string to time tuple according to format specification
tzset() -- change the local timezone

看看localtime（）及其逆mktime（），为什么gmtime（）没有逆呢

---

额外问题：你会给这个方法起什么名字？您将如何实现它？

我一直认为时间和日期时间模块有点不一致。无论如何，这是mktime的倒数

import time
def mkgmtime(t):
    """Convert UTC tuple to seconds since Epoch"""
    return time.mktime(t)-time.timezone

---

我只是Python的新手，但这里是我的方法

def mkgmtime(fields):
    now = int(time.time())
    gmt = list(time.gmtime(now))
    gmt[8] = time.localtime(now).tm_isdst
    disp = now - time.mktime(tuple(gmt))
    return disp + time.mktime(fields)

还有，我建议的函数名称：：-）每次重新计算

disp

很重要，以防夏令时值发生变化或类似情况。（Jython需要转换回元组。CPython似乎不需要它。）

---

这是超级点击，因为

time.gmtime

总是将DST标志设置为false。不过，我讨厌代码。一定有更好的办法。可能还有一些我还没有得到的情况。

实际上有一个反函数，但出于一些奇怪的原因，它在模块中：calendar.timegm（）。我在这里列出了函数。

mktime文档在这里有点误导，没有意义说它是作为本地时间计算的，而是根据提供的元组计算从历元算起的秒数，而不管计算机的位置如何

如果确实要将utc参数转换为本地时间，可以执行以下操作：

>>> time.ctime(time.time())
'Fri Sep 13 12:40:08 2013'

>>> utc_tuple = time.gmtime()
>>> time.ctime(time.mktime(utc_tuple))
'Fri Sep 13 10:40:11 2013'

>>> time.ctime(time.mktime(utc_tuple) - time.timezone)
'Fri Sep 13 12:40:11 2013'

也许更准确的问题是如何将utc\u元组转换为本地\u元组。 我称之为gm\u tuple\u to\u local\u tuple（我更喜欢长而描述性的名称）：

验证：

>>> time.ctime(time.mktime(time.localtime(time.mktime(utc_tuple) - time.timezone)))
'Fri Sep 13 12:40:11 2013'    

希望这有帮助，

---

伊利亚。

要弄清楚是使用time.timezone还是time.altzone是很困难的一部分。：-）对于非Python人员：time.timezone是非DST时间增量。time.altzone是DST时间增量。据我所知，除了调用localtime（），没有真正的方法来判断时间戳是否落在DST上。第二个Jester，我认为你不能用时区进行减法，因为DST不在时区中，这只能得到localtime（不考虑DST）1

time.mktime（）

需要本地时间，而不像

calendar.timegm（）

需要UTC时间元组。这可能会导致距离误差。2.某些本地时间不明确或不存在，即有两个对应的时间戳或没有--

mktime（）

可能会在DST转换周围返回错误的结果。3. <代码>-时间。时区可能因DST（

altzone

）而不同，或者因为

t

时间的UTC偏移量与当前UTC偏移量不同。日历。timegm（datetime.datetime.utcnow（）.utctimetuple（））是获取UTC时间戳的一行程序。Python：包括电池，但有时电池本身并没有组装。@erikcw:或者在使用Unix epoch的系统上（在我所知道的每个系统上）只是

time.time（）

。+/-浮点/整数转换。这个答案是错误的。演示：

断言时间.gmtime（10**9）==（2001,9,9,1,46,406252,0）

assert time.mktime（（2001,9,9,1,46,406252,0））==10**9-4*3600

（当然，最后一个仅在某些系统上有效，取决于本地时区）。原因：

mktime

考虑了当地时区。

>>> time.ctime(time.mktime(time.localtime(time.mktime(utc_tuple) - time.timezone)))
'Fri Sep 13 12:40:11 2013'