时间.gmtime（）导致armhf平台上的溢出错误

Question

我有一个在Cubox（armhf平台）上运行的webserver（CherryPy），在启动wever时，我得到以下错误：

[14/Aug/2015:09:33:40] HTTP Traceback (most recent call last):
  File "(...)/lib/python3.4/site-packages/cherrypy/_cprequest.py", line 661, in respond
    self.hooks.run('before_request_body')
  File "(...)/lib/python3.4/site-packages/cherrypy/_cprequest.py", line 114, in run
    raise exc
  File "(...)/lib/python3.4/site-packages/cherrypy/_cprequest.py", line 104, in run
    hook()
  File "(...)/lib/python3.4/site-packages/cherrypy/_cprequest.py", line 63, in __call__
    return self.callback(**self.kwargs)
  File "(...)/lib/python3.4/site-packages/cherrypy/lib/sessions.py", line 901, in init
    httponly=httponly)
  File "(...)/lib/python3.4/site-packages/cherrypy/lib/sessions.py", line 951, in set_response_cookie
    cookie[name]['expires'] = httputil.HTTPDate(e)
  File "(...)/lib/python3.4/site-packages/cherrypy/_cpcompat.py", line 278, in HTTPDate
    return formatdate(timeval, usegmt=True)
  File "/usr/lib/python3.4/email/utils.py", line 177, in formatdate
    now = time.gmtime(timeval)
OverflowError: timestamp out of range for platform time_t

我不确定我是否正确地理解了这个问题，也不确定是否可以由我来解决。据我所知，这是由切里皮引起的。此错误会导致500 Internal Server Error，并且不会加载页面。在

如评论中所问，我插入了一个印刷品。我没看到什么特别的东西。这是启动服务器并尝试加载页面后的输出：

^{pr2}$

我不确定是哪个值导致了错误。我猜是前面有4个的那个？在windows计算机上，time.gmtime(4593151133.439074)返回一个包含2115年的结构。在

在Cubox上启动pythonshell并输入time.gmtime(4593151133.439074)我可以重现错误。但我不知道这些价值观从何而来。在

编辑

我找到了CherryPy中的文件和行，它返回指向2115年的浮点数。它是文件中的第949-951行会话.py公司名称：

if timeout:
    e = time.time() + (timeout * 60)
    cookie[name]['expires'] = httputil.HTTPDate(e)

我不知道为什么我的暂停时间这么长。在

Answer 1

要解决armhf平台上C gmtime()的范围限制，可以使用显式公式从POSIX时间戳as the docs suggest获取UTC时间：

>>> from datetime import datetime, timedelta
>>> datetime(1970, 1, 1) + timedelta(seconds=4593151133.439074)
datetime.datetime(2115, 7, 21, 11, 18, 53, 439074)
>>> datetime.utcfromtimestamp(4593151133.439074) # calls gmtime() internally
datetime.datetime(2115, 7, 21, 11, 18, 53, 439073) # almost same result on non-"right" timezones

Answer 2

我发现了问题。一位同事将超时设置为一个非常高的超时值，在32/64位体系结构的Linux或Windows上没有引起任何问题，但在armhf上。在

我可以通过将超时设置为较低的值来解决问题

cherrypy.request.config.update({'tools.sessions.timeout': 60})