plot/lines not working for datetime objects that span old dates

[ocehugo]

• [ 1.5.1 , 3.5, OSX] Matplotlib version, Python version and Platform (Windows, OSX, Linux ...)
• [ pip ] How did you install Matplotlib and Python (pip, anaconda, from source ...)

pyplot.plot is not plotting datetime objects if the time span is older than 1678. For those dates it's returns an error:

TypeError: float() argument must be a string or a number, not 'datetime.date'

How to reproduce:

import datetime
import matplotlib.pyplot as plt

#this works
x = [datetime.date(1678,1,1) + datetime.timedelta(days=i) for i in range(10)]
plt.plot(x,range(10))
#this do not
x = [datetime.date(1677,1,1) + datetime.timedelta(days=i) for i in range(10)]
plt.plot(x,range(10))

I would not expect to be limited to a certain calendar or time epoch to just plot dates. The error seems to be related to the self._invalidx and the numpy array conversion that bypass float instead of 'O'.

[efiring]

I can't reproduce this with v2.x or v1.5.x (from source) or v1.5.1 from Anaconda. In all cases I see a diagonal line for each time range.

[ocehugo]

Right you are. I just started another instance and the error do not occur. I can't reproduce again since I closed the other instance. I can remember this happening more than once but as you show hard to reproduce ( I believe this start to occurs somehow just after some plotting errors like plotting float x values followed by datetime x values, but I closed all figures accordingly). Will remember to track down if this happen again and try to reproduce in new instances.
Close?

[WeatherGod]

1678? What a strange coincidence:

Code Meaning Time span (relative) Time span (absolute)
h hour +/- 1.0e15 years [1.0e15 BC, 1.0e15 AD]
m minute +/- 1.7e13 years [1.7e13 BC, 1.7e13 AD]
s second +/- 2.9e12 years [ 2.9e9 BC, 2.9e9 AD]
ms millisecond +/- 2.9e9 years [ 2.9e6 BC, 2.9e6 AD]
us microsecond +/- 2.9e6 years [290301 BC, 294241 AD]
ns nanosecond +/- 292 years [ 1678 AD, 2262 AD] <-------
ps picosecond +/- 106 days [ 1969 AD, 1970 AD]
fs femtosecond +/- 2.6 hours [ 1969 AD, 1970 AD]
as attosecond +/- 9.2 seconds [ 1969 AD, 1970 AD]

So, looks like somewhere in the codepath, the datetimes got converted into
nanosecond resultion np.datetime64?

On Tue, Jul 19, 2016 at 3:12 AM, Hugo Oliveira notifications@github.com
wrote:

Right you are. I just started another instance and the error do not occur.
I can't reproduce again since I closed the other instance. I can remember
this happening more than once but as you show hard to reproduce ( I believe
this start to occurs somehow just after some plotting errors like plotting
float x values followed by datetime x values, but I closed all figures
accordingly). Will remember to track down if this happen again and try to
reproduce in new instances.

—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
#6796 (comment),
or mute the thread
https://github.com/notifications/unsubscribe-auth/AARy-G_0L0MxQnDXhBo7txezYa1xlGadks5qXHjvgaJpZM4JPZlZ
.

[WeatherGod]

Arg! the formatting got messed up.... see the link here:
http://docs.scipy.org/doc/numpy/reference/arrays.datetime.html#datetime-units

On Tue, Jul 19, 2016 at 10:42 AM, Benjamin Root ben.v.root@gmail.com
wrote:

1678? What a strange coincidence:

Code Meaning Time span (relative) Time span (absolute) h hour +/- 1.0e15
years [1.0e15 BC, 1.0e15 AD] m minute +/- 1.7e13 years [1.7e13 BC, 1.7e13
AD] s second +/- 2.9e12 years [ 2.9e9 BC, 2.9e9 AD] ms millisecond +/-
2.9e9 years [ 2.9e6 BC, 2.9e6 AD] us microsecond +/- 2.9e6 years [290301
BC, 294241 AD] ns nanosecond +/- 292 years [ 1678 AD, 2262 AD]
<-------
ps picosecond +/- 106 days [ 1969 AD, 1970 AD] fs femtosecond +/- 2.6
hours [ 1969 AD, 1970 AD] as attosecond +/- 9.2 seconds [ 1969 AD, 1970 AD]

So, looks like somewhere in the codepath, the datetimes got converted into
nanosecond resultion np.datetime64?

On Tue, Jul 19, 2016 at 3:12 AM, Hugo Oliveira notifications@github.com
wrote:

Right you are. I just started another instance and the error do not
occur. I can't reproduce again since I closed the other instance. I can
remember this happening more than once but as you show hard to reproduce (
I believe this start to occurs somehow just after some plotting errors like
plotting float x values followed by datetime x values, but I closed all
figures accordingly). Will remember to track down if this happen again and
try to reproduce in new instances.

—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
#6796 (comment),
or mute the thread
https://github.com/notifications/unsubscribe-auth/AARy-G_0L0MxQnDXhBo7txezYa1xlGadks5qXHjvgaJpZM4JPZlZ
.

[efiring]

Pandas datetime uses datetime64[ns]--I'll bet that when the OP ran into the problem, datetime had been imported from Pandas, overriding an import from the datetime standard library.

[ocehugo]

@WeatherGod , yes I look into this before, and you and @efiring iring are right, it's a reassigment/import overwrite probably by Pandas (more specifically statsmodels package). To reproduce:

import datetime
import matplotlib.pyplot as plt
import statsmodels.api as sm
x = [datetime.date(1677,1,1) + datetime.timedelta(days=i) for i in range(10)]
plt.plot(x,range(10)

As stated the problem is with the import of statsmodels and it's internals. This was a surprise and make me wonder to change all the order of my imports...Any clues if there is a package to check for those kind of things before running code? Just wondering about correctness/testing of some code facing packages/versions.

Also, should report this to statsmodels!?

[tacaswell]

I would report this to statsmodels.

The other solution is to put your list into a pd.Series which boxes the dt64 objects into something that will be handled via the unit framework by code from pandas.

[ocehugo]

thanks @tacaswell, will do it. Your solution it's more complicated for me (have to import Pandas, call the series and convert back to numpy arrays/list of datetimes - my usage). The problem was I just want a single function of statsmodels in another class/fun in the same source code ( and was not expected that importing this would change the behaviour or the whole source code!). That func in fact is not used for datetime objects, just to estimate some Confidence intervals from a fit not used/related at all with datetimes. This was hard to spot since that import line is atop the source and in my jupyter initialization.

[efiring]

I think this is a pandas issue. In your example above, importing pandas instead of statsmodels yields the same error. Statsmodels imports pandas, which registers its own converter. Based on a quick look at the code in pandas still I don't understand the problem, because it looks like the pandas converter should fall back in this instance to the mpl converter; but in any case, I think pandas is the root of the problem.