<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">2013/4/18 Chris Barker - NOAA Federal <span dir="ltr"><<a href="mailto:chris.barker@noaa.gov" target="_blank">chris.barker@noaa.gov</a>></span><br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<div class="im">On Wed, Apr 17, 2013 at 1:09 PM, Bob Nnamtrop <<a href="mailto:bob.nnamtrop@gmail.com">bob.nnamtrop@gmail.com</a>> wrote:<br>
> It would seem that before 1970 the dates do not include the time zone<br>
> adjustment while after 1970 they do. This is the source of the extra 7<br>
> hours.<br>
><br>
> In [21]: np.datetime64('1970-01-01 00')<br>
> Out[21]: numpy.datetime64('1970-01-01T00:00-0700','h')<br>
><br>
> In [22]: np.datetime64('1969-12-31 00')<br>
> Out[22]: numpy.datetime64('1969-12-31T00:00Z','h')<br>
<br>
</div>wow! that is so wrong, and confusing -- I thought I had an idea what<br>
was going on here:<br>
<br>
datetime64 currently does a timezone adjustment at two places:<br>
<br>
1) when constructing a datetime64 from an ISO string<br>
2) when constructing an ISO string from a datetime64<br>
<br>
This:<br>
In [110]: np.datetime64('1969-12-31 00').view(np.int64)<br>
Out[110]: -24<br>
<br>
In [111]: np.datetime64('1970-01-01 00').view(np.int64)<br>
Out[111]: 8<br>
<br>
indicates that it is doing the input transition differently, as the<br>
underlying value is wrong for one.<br>
(another weird note -- I;m in pacific time, which is -7 now, with<br>
DST....so why the 8?)<br>
<br>
That explains the timedelta error.<br>
<br>
But the output is odd, too:<br>
<br>
In [117]: np.datetime64(datetime.datetime(1969, 12, 31, 0))<br>
Out[117]: numpy.datetime64('1969-12-31T00:00:00.000000Z')<br>
<br>
In [118]: np.datetime64(datetime.datetime(1970, 1, 1, 0))<br>
Out[118]: numpy.datetime64('1969-12-31T16:00:00.000000-0800')<br>
<br>
(when converting datetime.datetime objects, no timezone adjustment is applied)<br>
<br>
I suspect that it's trying to use the system time functions (which wil<br>
apply the locale), but that they don't work before 1970...at least on<br>
*nix machines.<br>
<br>
ANyone tested this on Windows?<br></blockquote><div><br></div><div>On Windows 7, numpy 1.7.0 (Anaconda 1.4.0 64 bit), I don't even get a wrong answer, but an error:<br><br></div><div>In [3]: np.datetime64('1969-12-31 00')<br>
Out[3]: numpy.datetime64('1969-12-31T00:00Z','h')<br><br>In [4]: np.datetime64('1970-01-01 00')<br>---------------------------------------------------------------------------<br>OSError Traceback (most recent call last)<br>
<ipython-input-4-ebf323268a4e> in <module>()<br>----> 1 np.datetime64('1970-01-01 00')<br><br>OSError: Failed to use 'mktime' to convert local time to UTC<br></div><div><br> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
We REALLY need to fix this!<br>
<span class=""><font color="#888888"><br>
-Chris<br>
</font></span><div class=""><div class="h5"><br>
<br>
<br>
<br>
<br>
<br>
<br>
<br>
<br>
> I saw the other thread about the time zone issues and I think getting rid of<br>
> timezones (perhaps unless they are explicitly requested) is the right thing<br>
> to do.<br>
><br>
> Bob<br>
><br>
><br>
> On Tue, Apr 16, 2013 at 4:55 PM, Bob Nnamtrop <<a href="mailto:bob.nnamtrop@gmail.com">bob.nnamtrop@gmail.com</a>><br>
> wrote:<br>
>><br>
>> I am curious if others have noticed an issue with datetime64 at the<br>
>> beginning of 1970. First:<br>
>><br>
>> In [144]: (np.datetime64('1970-01-01') - np.datetime64('1969-12-31'))<br>
>> Out[144]: numpy.timedelta64(1,'D')<br>
>><br>
>> OK this look fine, they are one day apart. But look at this:<br>
>><br>
>> In [145]: (np.datetime64('1970-01-01 00') - np.datetime64('1969-12-31<br>
>> 00'))<br>
>> Out[145]: numpy.timedelta64(31,'h')<br>
>><br>
>> Hmmm, seems like there are 7 extra hours? Am I missing something? I don't<br>
>> see this at any other year. This discontinuity makes it hard to use the<br>
>> datetime64 object without special adjustment in ones code. I assume this a<br>
>> bug?<br>
>><br>
>> Thanks,<br>
>> Bob<br>
>><br>
>> ps I'm using the most recent anaconda release on mac os x 10.6.8 which<br>
>> includes numpy 1.7.0.<br>
>><br>
>> pss It would be most handy if datetime64 had a constructor of the form<br>
>> np.datetime64(year,month,day,hour,min,sec) where these inputs were numpy<br>
>> arrays and the output would have the same shape as the input arrays (but be<br>
>> of type datetime64). The hour,min,sec would be optional. Scalar inputs would<br>
>> be broadcast to the size of the array inputs, etc. Maybe this is a topic for<br>
>> another post.<br>
><br>
><br>
><br>
</div></div><div class="im">> _______________________________________________<br>
> NumPy-Discussion mailing list<br>
> <a href="mailto:NumPy-Discussion@scipy.org">NumPy-Discussion@scipy.org</a><br>
> <a href="http://mail.scipy.org/mailman/listinfo/numpy-discussion" target="_blank">http://mail.scipy.org/mailman/listinfo/numpy-discussion</a><br>
><br>
<br>
<br>
<br>
</div><div class="im">--<br>
<br>
Christopher Barker, Ph.D.<br>
Oceanographer<br>
<br>
Emergency Response Division<br>
NOAA/NOS/OR&R <a href="tel:%28206%29%20526-6959" value="+12065266959">(206) 526-6959</a> voice<br>
7600 Sand Point Way NE <a href="tel:%28206%29%20526-6329" value="+12065266329">(206) 526-6329</a> fax<br>
Seattle, WA 98115 <a href="tel:%28206%29%20526-6317" value="+12065266317">(206) 526-6317</a> main reception<br>
<br>
<a href="mailto:Chris.Barker@noaa.gov">Chris.Barker@noaa.gov</a><br>
</div><div class=""><div class="h5">_______________________________________________<br>
NumPy-Discussion mailing list<br>
<a href="mailto:NumPy-Discussion@scipy.org">NumPy-Discussion@scipy.org</a><br>
<a href="http://mail.scipy.org/mailman/listinfo/numpy-discussion" target="_blank">http://mail.scipy.org/mailman/listinfo/numpy-discussion</a><br>
</div></div></blockquote></div><br></div></div>