It would seem that before 1970 the dates do not include the time zone
adjustment while after 1970 they do. This is the source of the extra 7
hours.
In [21]: np.datetime64('1970-01-01 00')
Out[21]: numpy.datetime64('1970-01-01T00:00-0700','h')
In [22]: np.datetime64('1969-12-31 00')
Out[22]: numpy.datetime64('1969-12-31T00:00Z','h')
I saw the other thread about the time zone issues and I think getting rid
of timezones (perhaps unless they are explicitly requested) is the right
thing to do.
Bob
On Tue, Apr 16, 2013 at 4:55 PM, Bob Nnamtrop <bob.nnamt...@gmail.com>wrote:
> I am curious if others have noticed an issue with datetime64 at the
> beginning of 1970. First:
>
> In [144]: (np.datetime64('1970-01-01') - np.datetime64('1969-12-31'))
> Out[144]: numpy.timedelta64(1,'D')
>
> OK this look fine, they are one day apart. But look at this:
>
> In [145]: (np.datetime64('1970-01-01 00') - np.datetime64('1969-12-31 00'))
> Out[145]: numpy.timedelta64(31,'h')
>
> Hmmm, seems like there are 7 extra hours? Am I missing something? I don't
> see this at any other year. This discontinuity makes it hard to use the
> datetime64 object without special adjustment in ones code. I assume this a
> bug?
>
> Thanks,
> Bob
>
> ps I'm using the most recent anaconda release on mac os x 10.6.8 which
> includes numpy 1.7.0.
>
> pss It would be most handy if datetime64 had a constructor of the form
> np.datetime64(year,month,day,hour,min,sec) where these inputs were numpy
> arrays and the output would have the same shape as the input arrays (but be
> of type datetime64). The hour,min,sec would be optional. Scalar inputs
> would be broadcast to the size of the array inputs, etc. Maybe this is a
> topic for another post.
>
_______________________________________________
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
http://mail.scipy.org/mailman/listinfo/numpy-discussion
