10000 dates.date2num no longer works with numpy.datetime64 · Issue #2259 · matplotlib/matplotlib · GitHub
[go: up one dir, main page]
Skip to content

dates.date2num no longer works with numpy.datetime64 #2259

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom
Closed
fonnesbeck opened this issue Jul 30, 2013 · 12 comments
Closed

dates.date2num no longer works with numpy.datetime64 #2259

fonnesbeck opened this issue Jul 30, 2013 · 12 comments
Labels
third-party integration topic: date handling
Milestone
v2.2.0

Comments

@fonnesbeck
Copy link

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 data looks like this:

In[18: time[:4]
Out[18]:
95    2010-04-12 07:23:12
96    2010-06-10 20:43:07
100   2010-06-21 06:37:28
221   2009-07-20 06:53:38
Name: st_time, dtype: datetime64[ns]

This worked prior to the update. Running yesterday's master on OS X 10.8.4 and Python 2.7.2.
@efiring
Copy link
Member
efiring commented 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
Copy link
Member
pelson commented Jul 31, 2013

Any chance you could provide a SSCCE?

@fonnesbeck
Copy link
Author

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.

This was referenced May 24, 2014
Closed
Open
@tacaswell tacaswell modified the milestones: v1.4.x, v1.4.0, v1.5.x Aug 17, 2014
@tacaswell
Copy link
Member

Punting this back to 1.5.x, as there is work-around, see https://github.com/pydata/pandas/pull/8054/files

@tacaswell
Copy link
Member

@fonnesbeck Do you need date2time to work for your own reasons or is this just for plotting?

@fonnesbeck
Copy link
Author

This was so long ago I can't remember what my work-around was. I believe it was for plotting only, however.

@tacaswell tacaswell modified the milestones: 2.1 (next point release), 2.2 (next next feature release) Oct 3, 2017
@sashkab
Copy link
sashkab commented 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
Copy link
Member
WeatherGod commented Nov 28, 2017 via email

@jklymak
Copy link
Member
jklymak commented Nov 28, 2017

#9779 is an in-house fix...

pandas issue: pandas-dev/pandas#18301

Work around:

from pandas.tseries import converter
converter.register()

@jklymak
Copy link
Member
jklymak commented Nov 28, 2017

I'm going to close this given #9779, and the SSCCE is not available anymore.

@jklymak jklymak closed this as completed Nov 28, 2017
@sashkab
Copy link
sashkab commented 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
Copy link
Member
efiring commented 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.

@QuLogic QuLogic modified the milestones: needs sorting, v2.2.0 Feb 12, 2018
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
third-party integration topic: date handling
Projects
None yet
Milestone
v2.2.0
Development

No branches or pull requests
9 participants
@fonnesbeck @efiring @tacaswell @WeatherGod @QuLogic @pelson @sashkab @story645 @jklymak
0