EPOCH definition fails on win10 py3.6

[ThomasLecocq]

Problem Description
Hi,
I'm (almost done) adapting our seismogram picking software built on traitsui+chaco to py3.

This line:

chaco/chaco/scales/safetime.py

Line 15 in 7c61319

EPOCH = datetime.fromtimestamp(0.0)

fails on win10 x64 py3.6

The minimum value acceptable is 86400

Reproduction Steps:

In [1]: import datetime

In [2]: datetime.datetime.fromtimestamp(0)
---------------------------------------------------------------------------
OSError                                   Traceback (most recent call last)
<ipython-input-2-ca3d263171b9> in <module>()
----> 1 datetime.datetime.fromtimestamp(0)

OSError: [Errno 22] Invalid argument

In [3]: datetime.datetime.fromtimestamp(86400)
Out[3]: datetime.datetime(1970, 1, 2, 1, 0)

Expected behavior:
I'd suspect that the desired behaviour is

epoch = datetime.datetime(1970,1,1)

but then, this might fail if another "0.0" is defined ?

OS, Python version:
Win10 x64 Py3.6 (Python 3.6.2 | Anaconda custom (64-bit))

[jvkersch]

A description of the underlying issue is given here: https://bugs.python.org/issue29097

Not sure what the appropriate fix is, I'm not overly familiar with that part of the code. Will look at it some more soon, unless someone beats me to it.

[corranwebster]

I went over the timescale code in a fairly detailed manner last year because we had tests which passed if you were in one timezone and failed if you were in another (or if daylight savings was in force...)

But no, datetime.datetime(1970, 1, 1) won't work: in my current TZ (BST) they give different results:

>>> datetime.datetime(1970, 1, 1)
datetime.datetime(1970, 1, 1, 0, 0)
>>> datetime.datetime.fromtimestamp(0)
datetime.datetime(1970, 1, 1, 1, 0)

I'm guessing that that the appropriate work-around is to do something gross like datetime.datetime.fromtimestamp(86400) - 86400 no, that won't work, needs to be a timedelta: datetime.datetime.fromtimestamp(86400) - datetime.timedelta(seconds=86400)

[corranwebster]

Possibly need to catch OSError in safe_fromtimestamp as well.

[ThomasLecocq]

Maybe check what we do in Obspy:
https://github.com/obspy/obspy/blob/e9415de1f5a11c0f6ac01f845a342108f88fde36/obspy/core/utcdatetime.py

@krischer @megies, any idea ?

[corranwebster]

If you have your own time-handling code that you are happy with, a possible work-around might be to write your own version of TimeScale

chaco/chaco/scales/time_scale.py

Line 206 in 7c61319

class TimeScale(AbstractScale):

that uses the ObsPy class instead of the current datetime handling.

Unfortunately the scales section of the Chaco codebase isn't particularly clear...

[ThomasLecocq]

tbh I'd rather use default chaco stuff if we could find a way to workaround this ... In my world we only use UTC time, so timezones etc were always an issue when using the TimeScale, but still... built-in is nicer...

[jvkersch]

timedelta: datetime.datetime.fromtimestamp(86400) - datetime.timedelta(seconds=86400)

@corranwebster Do you think this is ready to be rolled into a PR?

[corranwebster]

I guess. I don't like it but with sufficient comments to explain why on earth we are doing it, and making the magic number clearer (eg. a constant like DAY_SECONDS = 24*60*60) I think this is the simplest work-around.

[jvkersch]

I think this is the simplest work-around.

Let's go with that workaround then. If possible I'd like to fold this into the 4.7.1 release.

[jvkersch]

Addressed in #387, closing this issue. @ThomasLecocq Things should be fixed in master and a release is forthcoming (though I don't know the time scale for that).

[jvkersch]

Thanks for reporting!