On Wed, Apr 17, 2013 at 1:09 PM, Bob Nnamtrop <bob.nnamt...@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
> 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')
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
This:
In [110]: np.datetime64('1969-12-31 00').view(np.int64)
Out[110]: -24
In [111]: np.datetime64('1970-01-01 00').view(np.int64)
Out[111]: 8
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 [117]: np.datetime64(datetime.datetime(1969, 12, 31, 0))
Out[117]: numpy.datetime64('1969-12-31T00:00:00.000000Z')
In [118]: np.datetime64(datetime.datetime(1970, 1, 1, 0))
Out[118]: numpy.datetime64('1969-12-31T16:00:00.000000-0800')
(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
*nix machines.
ANyone tested this on Windows?
We REALLY need to fix this!
-Chris
> 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
>
--
Christopher Barker, Ph.D.
Oceanographer
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.bar...@noaa.gov
_______________________________________________
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
http://mail.scipy.org/mailman/listinfo/numpy-discussion
