[Numpy-discussion] datetime64 1970 issue
bob.nnamtrop at gmail.com
Wed Apr 17 16:09:25 EDT 2013
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
In : np.datetime64('1970-01-01 00')
In : np.datetime64('1969-12-31 00')
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.
On Tue, Apr 16, 2013 at 4:55 PM, Bob Nnamtrop <bob.nnamtrop at gmail.com>wrote:
> I am curious if others have noticed an issue with datetime64 at the
> beginning of 1970. First:
> In : (np.datetime64('1970-01-01') - np.datetime64('1969-12-31'))
> Out: numpy.timedelta64(1,'D')
> OK this look fine, they are one day apart. But look at this:
> In : (np.datetime64('1970-01-01 00') - np.datetime64('1969-12-31 00'))
> Out: 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
> 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.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the NumPy-Discussion