Windows 10: OverflowError: mktime argument out of range

[martin-neotech]

The C library function on windows 10 does not support times below a certain value.

https://github.com/neo4j/neo4j-python-driver/blob/4.0/neo4j/time/__init__.py#L239

    @classmethod
    def local_offset(cls):
        """ The offset from UTC for local time read from this clock.
        """
        return ClockTime(-int(mktime(gmtime(0))))

python time module

Although this module is always available, not all functions are available on all platforms. 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.

The epoch is the point where the time starts, and is platform dependent. For Unix, the epoch is January 1, 1970, 00:00:00 (UTC). To find out what the epoch is on a given platform, look at time.gmtime(0).

https://docs.python.org/3/library/time.html

>>> time.gmtime(0)
time.struct_time(tm_year=1970, tm_mon=1, tm_mday=1, tm_hour=0, tm_min=0, tm_sec=0, tm_wday=3, tm_yday=1, tm_isdst=0)

>>> list((ix for ix in time.gmtime(0)))
[1970, 1, 1, 0, 0, 0, 3, 1, 0]

>>> time.mktime(time.gmtime(0))
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
OverflowError: mktime argument out of range

[XuCcc]

the same error on windows10

r = time.struct_time(tm_year=1900, tm_mon=1, tm_mday=1, tm_hour=8, tm_min=0, tm_sec=0, tm_wday=0, tm_yday=1, tm_isdst=-1)
time.mktime(r)

it raise an error that OverflowError: mktime argument out of range

[martin-neotech]

@XuCcc Thanks for the feedback.

[martin-neotech]

This is basically a documentation issue, https://docs.python.org/3/library/datetime.html#datetime.date.fromtimestamp that if the underlying C library does not support the operation it throws an OverflowError

[martin-neotech]

#427

[edgarbenet]

I am facing this issue on my windows platform. I can't find how to solve this issue. Is it documented somewhere any walkaround of it?

[martin-neotech]

@edgarbenet you probably need to find a third party library that can cope with this issue.

[robsdedude]

@edgarbenet Yesterday, I released version 4.3.5 with a patch that should improve compatibility with Windows. Could you please check whether it resolves the issue for you?
If not, I'd be interested in which Windows version you're running and to which timezone it is set to.

[TomasKoutek]

Hi,
i am using python 3.9 on windows 10 and i had the same problem. The solution for me is to set the timezone globally (os.environ['TZ'] = 'Europe/Prague'). Because "mktime(gmtime(0))" is called during import, it is necessary to set it as an environment variable for the script and not in the code - "TZ=Europe/Prague python myscript.py" or in Pycharm it is in the section "Run Configuration" -> "Environment variable".

[hasinthaK]

@TomasKoutek It worked as you have mentioned, I was actually going to use WSL for this since the project I'm working on uses Flask & apparently Flask has some peer deps which uses this, & raises the exception, thus I'm not able to edit the code as some answers have suggested over here.

but didn't catch why it's working when the TZ is set,

[robsdedude]

@TomasKoutek, @hasinthaK can you confirm if the issue is still present or fixed in version 4.3.5 or 4.3.6?

And to answer you question @hasinthaK gmtime(0) will construct the epoch time in UTC. mktime(gmtime(0)) will then convert that time to your local time. If that local time is east of UTC (or if daylight saving time causes it to be UTC-...), the resulting time will be pre-epoch. Windows is not happy with this.

[technige]

@robsdedude This might help you....

As stated above, mktime(x) where x < 0 fails on Windows but succeeds on Linux. To that end, you can replace this code...

mktime(gmtime(0))

... with this code ...

mktime(gmtime(86400)) - 86400

This should give you the same end result, but stops the argument for mktime dipping below zero by temporarily offsetting by the number of seconds in a day (no time zone offset should ever exceed that).

[robsdedude]

@technige thanks a bunch for the hint. The same thing came to my mind a few weeks back :D
But for that extra bit of safety with daylight saving or what ever surprises are slumbering in the world of dates and times, I opted to offset it by 48 hours.
https://github.com/neo4j/neo4j-python-driver/pull/588/files#diff-157b9ad263644e8ce83c3ed2ac325f859087d543c5f10cf038dd24ecafde09b9L269-R272

It should be fixed in 4.3.5+