After updating matplotlib from master yesterday, calling dates.date2num on either a Pandas Series or a numpy array of numpy.datetime64 types raises an AttributeError:
---------------------------------------------------------------------------
AttributeError Traceback (most recent call last)
<ipython-input-16-9050e29ead3a> in <module>()
1 data = dataset[dataset.sma=='SE']
2 time = data.st_time
----> 3 dates.date2num(time[data.active==0].values)
/Library/Python/2.7/site-packages/matplotlib-1.4.x-py2.7-macosx-10.8-intel.egg/matplotlib/dates.pyc in date2num(d)
292 if not d.size:
293 return d
--> 294 return _to_ordinalf_np_vectorized(d)
295
296
/Library/Python/2.7/site-packages/numpy-1.8.0.dev_b307a8a_20130729-py2.7-macosx-10.8-intel.egg/numpy/lib/function_base.pyc in __call__(self, *args, **kwargs)
1896 vargs.extend([kwargs[_n] for _n in names])
1897
-> 1898 return self._vectorize_call(func=func, args=vargs)
1899
1900 def _get_ufunc_and_otypes(self, func, args):
/Library/Python/2.7/site-packages/numpy-1.8.0.dev_b307a8a_20130729-py2.7-macosx-10.8-intel.egg/numpy/lib/function_base.pyc in _vectorize_call(self, func, args)
1956 _res = func()
1957 else:
-> 1958 ufunc, otypes = self._get_ufunc_and_otypes(func=func, args=args)
1959
1960 # Convert args to object arrays first
/Library/Python/2.7/site-packages/numpy-1.8.0.dev_b307a8a_20130729-py2.7-macosx-10.8-intel.egg/numpy/lib/function_base.pyc in _get_ufunc_and_otypes(self, func, args)
1920 # arrays (the input values are not checked to ensure this)
1921 inputs = [asarray(_a).flat[0] for _a in args]
-> 1922 outputs = func(*inputs)
1923
1924 # Performance note: profiling indicates that -- for simple functions
/Library/Python/2.7/site-packages/matplotlib-1.4.x-py2.7-macosx-10.8-intel.egg/matplotlib/dates.pyc in _to_ordinalf(dt)
195 dt -= delta
196
--> 197 base = float(dt.toordinal())
198 if hasattr(dt, 'hour'):
199 base += (dt.hour / HOURS_PER_DAY + dt.minute / MINUTES_PER_DAY +
AttributeError: 'numpy.datetime64' object has no attribute 'toordinal'
The fact that it worked before looks like an accident. mpl has never supported numpy datetime64. Surely we will do so eventually, once this dtype settles down. Perhaps we can start with this particular example, by figuring out why the conversion accidentally did work before it was vectorized.
Absolutely. Again, this worked for weeks prior to building a new matplotlib from master the other day, which is why I think something had changed in mpl.
Did you also happen to upgrade pandas and are using pandas? The support for
datetime64 actually came from pandas registering a converter upon import,
but the latest version of pandas did not do that.
I'm not using pandas, only numpy. Somehow this worked for us upto and including in 2.0.2. Is there an eta when #9779 will be released? Is it scheduled for patch release, or for the next minor release, i.e 2.3.0?
When it was working, I suspect that pandas was being imported, even if you weren't actually using it. Just the import was sufficient to install its converters. #9779 will not go into the next bug-fix release (2.1.1) which is imminent, but it will go into 2.2, which I hope will be out by the end of the year.
Activity
efiring commented on Jul 30, 2013
The fact that it worked before looks like an accident. mpl has never supported numpy datetime64. Surely we will do so eventually, once this dtype settles down. Perhaps we can start with this particular example, by figuring out why the conversion accidentally did work before it was vectorized.
pelson commented on Jul 31, 2013
Any chance you could provide a SSCCE?
fonnesbeck commented on Jul 31, 2013
Absolutely. Again, this worked for weeks prior to building a new matplotlib from master the other day, which is why I think something had changed in mpl.
tacaswell commented on Aug 20, 2014
Punting this back to 1.5.x, as there is work-around, see https://github.com/pydata/pandas/pull/8054/files
tacaswell commented on Dec 5, 2015
@fonnesbeck Do you need date2time to work for your own reasons or is this just for plotting?
fonnesbeck commented on Dec 6, 2015
This was so long ago I can't remember what my work-around was. I believe it was for plotting only, however.
sashkab commented on Nov 28, 2017
I've run into this issue after upgrading from 2.0.2 to 2.1.0. I have an array of dtype='datetime64[D]', which causing similar exception.
WeatherGod commented on Nov 28, 2017
jklymak commented on Nov 28, 2017
#9779 is an in-house fix...
pandas issue: pandas-dev/pandas#18301
Work around:
jklymak commented on Nov 28, 2017
I'm going to close this given #9779, and the SSCCE is not available anymore.
sashkab commented on Nov 28, 2017
I'm not using pandas, only numpy. Somehow this worked for us upto and including in 2.0.2. Is there an eta when #9779 will be released? Is it scheduled for patch release, or for the next minor release, i.e 2.3.0?
efiring commented on Nov 28, 2017
When it was working, I suspect that pandas was being imported, even if you weren't actually using it. Just the import was sufficient to install its converters.
#9779 will not go into the next bug-fix release (2.1.1) which is imminent, but it will go into 2.2, which I hope will be out by the end of the year.