[Numpy-discussion] datetime64 1970 issue
Chris Barker - NOAA Federal
chris.barker at noaa.gov
Wed Apr 17 19:10:39 EDT 2013
On Wed, Apr 17, 2013 at 1:09 PM, Bob Nnamtrop <bob.nnamtrop at gmail.com> wrote:
> 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')
> Out: numpy.datetime64('1970-01-01T00:00-0700','h')
> In : np.datetime64('1969-12-31 00')
> Out: numpy.datetime64('1969-12-31T00:00Z','h')
wow! that is so wrong, and confusing -- I thought I had an idea what
was going on here:
datetime64 currently does a timezone adjustment at two places:
1) when constructing a datetime64 from an ISO string
2) when constructing an ISO string from a datetime64
In : np.datetime64('1969-12-31 00').view(np.int64)
In : np.datetime64('1970-01-01 00').view(np.int64)
indicates that it is doing the input transition differently, as the
underlying value is wrong for one.
(another weird note -- I;m in pacific time, which is -7 now, with
DST....so why the 8?)
That explains the timedelta error.
But the output is odd, too:
In : np.datetime64(datetime.datetime(1969, 12, 31, 0))
In : np.datetime64(datetime.datetime(1970, 1, 1, 0))
(when converting datetime.datetime objects, no timezone adjustment is applied)
I suspect that it's trying to use the system time functions (which wil
apply the locale), but that they don't work before 1970...at least on
ANyone tested this on Windows?
We REALLY need to fix this!
> 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>
>> 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
>> 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.
> NumPy-Discussion mailing list
> NumPy-Discussion at scipy.org
Christopher Barker, Ph.D.
Emergency Response Division
NOAA/NOS/OR&R (206) 526-6959 voice
7600 Sand Point Way NE (206) 526-6329 fax
Seattle, WA 98115 (206) 526-6317 main reception
Chris.Barker at noaa.gov
More information about the NumPy-Discussion