Maximum value of timestamp

Question

I am using Python 3.6.0 on Windows 10 x64.

I just found that in time.ctime(seconds), seconds parameter has an implicit maximum value, which

Answer 1

I'm using 3.6.1 |Continuum Analytics, Inc.| (default, May 11 2017, 13:09:58) \n[GCC 4.4.7 20120313 (Red Hat 4.4.7-1)] in a Ubuntu 16.04 VM running on a Windows 10 machine.

I broke apart your ctime call to its components, to investigate but I don't run into the same maximum.

>>> time.asctime(time.localtime(32536799999-1))
'Mon Jan 19 02:59:58 3001'
>>> time.asctime(time.localtime(32536799999+1))
'Mon Jan 19 03:00:00 3001'
>>> time.asctime(time.localtime(32536799999+10))
'Mon Jan 19 03:00:09 3001'
>>> time.asctime(time.localtime(32536799999+10000))
'Mon Jan 19 05:46:39 3001'
>>> time.asctime(time.localtime(32536799999+1000000))
'Fri Jan 30 16:46:39 3001'
>>> time.asctime(time.localtime(32536799999+1000000000))
'Thu Sep 27 05:46:39 3032'
>>> time.ctime(32536799999+1000000000)
'Thu Sep 27 05:46:39 3032'
>>> time.asctime(time.gmtime(32536799999-1))
'Mon Jan 19 07:59:58 3001'
>>> time.asctime(time.gmtime(32536799999+1))
'Mon Jan 19 08:00:00 3001'
>>> time.asctime(time.gmtime(32536799999+1000000000))
'Thu Sep 27 09:46:39 3032'

Either something was fixed from 3.6.0 to 3.6.1, or you have some interesting issue specific to your machine.

I do see the following time related change in 3.6.1: https://www.python.org/dev/peps/pep-0495/ I wonder if the time you happened to be using happened to fall into a fold or a gap? Could you try adding a little over 1 hour on your system and see if it becomes valid again?

Answer 2

The time documentation doesn't mention any limits, but the datetime documentation does:

fromtimestamp() may raise OverflowError, if the timestamp is out of the range of values supported by the platform C localtime() or gmtime() functions, and OSError on localtime() or gmtime() failure.

[...]

Naive datetime instances are assumed to represent local time and this method relies on the platform C mktime() function to perform the conversion. Since datetime supports wider range of values than mktime() on many platforms, this method may raise OverflowError for times far in the past or far in the future.

Then we head over to the Windows documentation:

_localtime64, which uses the __time64_t structure, allows dates to be expressed up through 23:59:59, December 31, 3000, coordinated universal time (UTC), whereas _localtime32 represents dates through 23:59:59 January 18, 2038, UTC.

localtime is an inline function which evaluates to _localtime64, and time_t is equivalent to __time64_t. If you need to force the compiler to interpret time_t as the old 32-bit time_t, you can define _USE_32BIT_TIME_T. Doing this will cause localtime to evaluate to _localtime32. This is not recommended because your application may fail after January 18, 2038, and it is not allowed on 64-bit platforms.

All the time-related functions (including ctime) work the same way. So the max date you can reliably convert between timestamps on Windows 10 is 3000-12-31T23:59:59Z.

Trying to get a platform-independent max timestamp is difficult.

Answer 3

This must be to do with your installation of Python, in version 3.5, I never experience such an error:

>>> time.ctime(32536799999)
'Mon Jan 19 07:59:59 3001'
>>> time.ctime(32536799999+1)
'Mon Jan 19 08:00:00 3001'
>>> time.ctime(32536799999+9999999999999999)
'Thu Feb 13 01:46:38 316890386'
>>> time.ctime(32536799999+99999999999999999)
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
OSError: [Errno 75] Value too large for defined data type

and even when I do with a gigantic number, it throws a different error.