10

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 is 32536799999, almost equals to 2^34.92135.

Is that the maximum value?

The error message just says it's an invalid number.

>>> import time
>>> time.ctime(32536799999)
>>> 'Mon Jan 19 15:59:59 3001'
>>> time.ctime(32536799999+1)
Traceback (most recent call last):
File "<stdin>", line 1, in <module>
OSError: [Errno 22] Invalid argument

I googled and looked on Python documentation, but I didn't find anything about it. And I'm going to check this problem on Ubuntu in my lab.

OrangeDog
  • 36,653
  • 12
  • 122
  • 207
Yaosen Min
  • 118
  • 1
  • 1
  • 7
  • `time.ctime` just calls a few OS-provided functions. The docs say `time.localtime(s) == time.asctime(time.localtime(s))`, so I would see which one of those calls fails on Windows. – Blender Sep 09 '17 at 17:35
  • 2
    Please don't post images of code or data. Welcome to SO - please take the time to read [ask] and [mcve]. – wwii Sep 09 '17 at 17:42
  • 2
    This is interesting, because according to Windows documentation, the maximum value shoud actually be already at [3000-12-31T23:59:59](https://msdn.microsoft.com/de-de/library/59w5xcdy.aspx#Anchor_1). – dhke Sep 09 '17 at 18:36
  • Hmm, `Python 3.6.2 (v3.6.2:5fd33b5, Jul 8 2017, 04:57:36) [MSC v.1900 64 bit (AMD64)] on win32` `>>> time.ctime(32536799999)` `'Mon Jan 19 09:59:59 3001'`. Same on `Python 3.5.3 (default, Sep 9 2017, 23:18:15) [MSC v.1900 64 bit (AMD64)] on win32`. – CristiFati Sep 09 '17 at 20:26
  • @wwii Thank you so much for letting me know, modified right away. – Yaosen Min Sep 10 '17 at 01:45

3 Answers3

8

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.

Community
  • 1
  • 1
OrangeDog
  • 36,653
  • 12
  • 122
  • 207
0

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?

Starman
  • 336
  • 2
  • 11
  • It seems this does not provide a promising answer since you are still investigating, you should put this in comments – Ibo Nov 14 '17 at 17:56
  • I cannot comment directly on questions until I have 50 reputation, and I think my details would not fit in a comment. I did some non-trivial work to investigate and provided at least a partial answer, including a direction to take for further investigation, so I think I will leave it to hopefully provide some answer value for the asker, or others who might arrive here after a search. – Starman Nov 15 '17 at 19:41
  • we had the same problem, we earned the privilege – Ibo Nov 15 '17 at 20:30
  • Indeed, I am participating in this process by answering. Previous answers I have provided before have earned me a few points here and there (as well as thanks for the help). I hope that my suggested answer, including link to documentation, and instructions on how to use that to test asker's particular setup, will help the asker confirm if my answer correctly identifies the problem. If not, I believe I have provided useful information for anyone who ends up here via a search on a related question. – Starman Nov 16 '17 at 22:02
  • You're running this on Ubuntu, not Windows. – OrangeDog Jun 14 '18 at 15:10
0

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.

Joe Iddon
  • 20,101
  • 7
  • 33
  • 54
  • 1
    In 3.6, on Windows, `datetime.datetime.max.timestamp()` raises `OSError: [Errno 22] Invalid argument`. You get a different one because you're on 3.5. – OrangeDog Jun 14 '18 at 14:52