I'm fairly sure it should be :numpy:class:`datetime64`, since "numpy" is the module name that intersphinx uses for lookup. I'll give it a go.

I don't know whether it is related, but the numpy docstring is misleading:

In [1]: import numpy

In [2]: numpy.datetime64?
Init signature: numpy.datetime64(self, /, *args, **kwargs)
Docstring:
Base class for numpy scalar types.

Class from which most (all?) numpy scalar types are derived.  For
consistency, exposes the same API as `ndarray`, despite many
consequent attributes being either "get-only," or completely irrelevant.
This is the class from which it is strongly suggested users should derive
custom scalar types.
File:           ~/anaconda/envs/test/lib/python3.5/site-packages/numpy/__init__.py
Type:           type

Never mind, ignore the above comment, I read the intersphinx docs completely wrong.

Probably because numpy forgot to add an intersphinx entry (see #9331 #8175 for similar instances on our side). I have a script to parse the intersphinx db somewhere...

python -m sphinx.ext.intersphinx 'https://docs.scipy.org/doc/numpy/objects.inv' | grep 'datetime64' doesn't output anything. (remove the grep to see the whole intersphinx inventory for numpy), so I think you're right @anntzer

Thanks all! Looks like its really an issue on their side, not ours. I'll leave open to monitor...

Oh nice, I never needed to write that script to start with then :p

This issue has been marked "inactive" because it has been 365 days since the last comment. If this issue is still present in recent Matplotlib releases, or the feature request is still wanted, please leave a comment and this label will be removed. If there are no updates in another 30 days, this issue will be automatically closed, but you are free to re-open or create a new issue if needed. We value issue reports, and this procedure is meant to help us resurface and prioritize issues that have not been addressed yet, not make them disappear. Thanks for your help!