[Numpy-discussion] datetime64 1970 issue

[Joris Van den Bossche]

2013/4/18 Chris Barker - NOAA Federal <chris.barker at noaa.gov>

> 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
> > 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?
>

On Windows 7, numpy 1.7.0 (Anaconda 1.4.0 64 bit), I don't even get a wrong
answer, but an error:

In [3]: np.datetime64('1969-12-31 00')
Out[3]: numpy.datetime64('1969-12-31T00:00Z','h')

In [4]: np.datetime64('1970-01-01 00')
---------------------------------------------------------------------------
OSError                                   Traceback (most recent call last)
<ipython-input-4-ebf323268a4e> in <module>()
----> 1 np.datetime64('1970-01-01 00')

OSError: Failed to use 'mktime' to convert local time to UTC



> 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.nnamtrop at 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 at 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.Barker at noaa.gov
> _______________________________________________
> NumPy-Discussion mailing list
> NumPy-Discussion at scipy.org
> http://mail.scipy.org/mailman/listinfo/numpy-discussion
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/numpy-discussion/attachments/20130418/c169e99b/attachment.html>