The issue is that datetime64 is always, unsurprisingly, 64 bits. Trying to
treat it as a 32-bit integer will give totally wrong results. In numpy
plain 'int' has the same width as a C 'long', which may be 32 or 64 bits;
but if you specify int32 or int64 then these are always available.

On Sun, Sep 1, 2013 at 3:24 PM, Daniel <notifications@github.com> wrote:

> In numpy/lib/function_base.py:
>
> > @@ -903,40 +905,82 @@ def gradient(f, *varargs):
> >      elif otype == 'm' :
> >          # Needs to keep the specific units, can't be a general unit
> >          otype = f.dtype
> > -
> > +
> > +    # Convert datetime64 data into ints. Make dummy variable `y`
> > +    # that is a view of ints if the data is datetime64, otherwise
> > +    # just set y equal to the the array `f`.
> > +    if f.dtype.char in ["M", "m"]:
> > +        y = f.view('int')
>
> Yes, I was hoping someone might comment. I didn't know whether numpy is
> fully 64 bit on so I stayed agnostic and went for the the vanilla 'int'
> type. So it's save to always use this? Yes, they are signed I think
> relative to UNIX time.
>
> —
> Reply to this email directly or view it on GitHub<https://github.com/numpy/numpy/pull/3654/files#r6102579>
> .
>