time.gmtime() causes OverflowError on armhf platform

Question

I have a webserver (CherryPy) running with on a Cubox (armhf platform) and upon starting the wever i get the following error:

[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

I'm not sure whether I understand the problem correctly and I am not sure if it can be fixed by me. As far as I can tell by the Traceback it is caused by CherryPy. This error causes a 500 Internal Server Error and won't load the page.

As asked in the comments I inserted a print. I don't see any thing special. This is the output of starting the server and once trying to load the page:

1439551125.1483066
1439551132.639804
4593151132.6458025
1439551132.723468
1439551132.7210276
1439551132.7268708
1439551132.7359934
1439551132.741787
1439551132.7452564
4593151132.750907
4593151132.762612
4593151132.749376
4593151132.731232
4593151132.754474
4593151132.763546
1439551132.8183882
4593151132.828029
1439551132.8379567
4593151132.856025
1439551132.8734775
1439551132.8554301
1439551132.879614
4593151132.884698
4593151132.890394
1439551132.8971672
4593151132.902081
4593151132.908171
1439551132.931757
4593151132.944052
1439551132.9759347
1439551132.9714596
4593151132.987068
4593151132.985899
1439551132.9926524
1439551133.0088623
4593151133.013047
1439551133.0280995
4593151133.040709
4593151133.029601
1439551133.0500746
4593151133.057341
1439551133.0749385
4593151133.081711
1439551133.1032782
4593151133.115171
1439551133.1194305
1439551133.1354048
4593151133.143136
4593151133.151044
1439551133.1612003
4593151133.16934
1439551133.1827784
4593151133.19687
1439551133.201899
4593151133.209947
1439551133.271833
4593151133.277573
1439551133.3090906
4593151133.312978
1439551133.3408027
4593151133.344741
1439551133.3722978
4593151133.376283
1439551133.4031894
4593151133.407124
1439551133.434834
4593151133.439074

I am not sure which of these values causes the error. I am guessing it's the one with 4 in front? On a windows machine time.gmtime(4593151133.439074) returns a struct which contains the year 2115.

On the Cubox when starting a python shell and entering time.gmtime(4593151133.439074) I can reproduce the error. But I don't know where these values come from.

EDIT

I have found the file and line in CherryPy that returns me the floating numbers which lead to the year 2115. It is line 949 - 951 in the file session.py:

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

Why I get such a high timeout, I don't know.

Abort

Have you set the systems time correctly? – Incandescence

@Incandescence I am running the server on Debian and the output of date is Fri Aug 14 09:54:41 CEST 2015. I guess the system time is correct then? – Abort

It also can be a Python bug on your platform. Can your put print(timeval) on the line 177 to see what value causes the overflow? – Saltzman

@Saltzman I have edited my question. – Abort

python -m trace --trace script.py – Stokes

Answer 1

I have found the issue. A coworker set the timeout to a very high value for timeout which didn't cause any issue on Linux or Windows with 32/64 Bit architecture but on armhf.

I was able to fix the problem by setting the timeout to a lower value via

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

Abort

I guess I makes sense open an issue in Pyton bugtracker if armhf is officially supported Python platform. I don't see neither restriction, nor a notice about amount of seconds to time.gmtime. – Saltzman

@saaj: "Most of the functions defined in this module call platform C library functions with the same name. It may sometimes be helpful to consult the platform documentation, because the semantics of these functions varies among platforms." Consult man 3 gmtime to find out the range restrictions. Or use datetime module that provides more portable semantics – Funderburk

Answer 2

To workaround the range limitation for C gmtime() on armhf platform, you could use the explicit formula to get the UTC time from a POSIX timestamp as the docs suggest:

>>> 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

Funderburk