On Wed, Apr 17, 2013 at 11:27 PM, Joris Van den Bossche
wrote:
>> 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')
>
On Wed, Apr 17, 2013 at 6:05 PM, Benjamin Root wrote:
> Aren't we on standard time at Jan 1st? So, at that date, you would have
> been -8.
yes, of course, pardon me for being an idiot.
-Chris
--
Christopher Barker, Ph.D.
Oceanographer
Emergency Response Division
NOAA/NOS/OR&R
On Thu, Apr 18, 2013 at 2:27 AM, Joris Van den Bossche <
jorisvandenboss...@gmail.com> wrote:
> 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.dat
2013/4/18 Chris Barker - NOAA Federal
> On Wed, Apr 17, 2013 at 1:09 PM, Bob Nnamtrop
> 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-0
On Wed, Apr 17, 2013 at 7:10 PM, Chris Barker - NOAA Federal <
chris.bar...@noaa.gov> wrote:
> On Wed, Apr 17, 2013 at 1:09 PM, Bob Nnamtrop
> 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
On Wed, Apr 17, 2013 at 1:09 PM, Bob Nnamtrop 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-0
On Wed, Apr 17, 2013 at 2:09 PM, Bob Nnamtrop 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-0
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
On Tue, Apr 16, 2013 at 3:55 PM, Bob Nnamtrop wrote:
> 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 datetime
On Wed, Apr 17, 2013 at 10:11 AM, Sebastian Berg
wrote:
> On Wed, 2013-04-17 at 09:07 -0700, Chris Barker - NOAA Federal wrote:
>> On Wed, Apr 17, 2013 at 9:04 AM, Chris Barker - NOAA Federal
>> wrote:
>> > On Tue, Apr 16, 2013 at 8:23 PM, Zachary Ploskey
>> > wrote:
>> > I'd say we need some m
On Wed, 2013-04-17 at 09:07 -0700, Chris Barker - NOAA Federal wrote:
> On Wed, Apr 17, 2013 at 9:04 AM, Chris Barker - NOAA Federal
> wrote:
> > On Tue, Apr 16, 2013 at 8:23 PM, Zachary Ploskey wrote:
> > I'd say we need some more unit-tests!
>
> speaking of which, where are the tests? I just d
On Wed, Apr 17, 2013 at 9:07 AM, Chris Barker - NOAA Federal
wrote:
> speaking of which, where are the tests? I just did a quick poke at
> github, and found:
>
> https://github.com/numpy/numpy/tree/master/numpy/testing
> and
> https://github.com/numpy/numpy/tree/master/numpy/test
>
> but there's v
On Wed, Apr 17, 2013 at 9:04 AM, Chris Barker - NOAA Federal
wrote:
> On Tue, Apr 16, 2013 at 8:23 PM, Zachary Ploskey wrote:
> I'd say we need some more unit-tests!
speaking of which, where are the tests? I just did a quick poke at
github, and found:
https://github.com/numpy/numpy/tree/master/
On Tue, Apr 16, 2013 at 8:23 PM, Zachary Ploskey wrote:
> The problem does not appear to exist on Linux with numpy version 1.6.2.
datetime64 was re-vampded a fair bit between 1.6 and 1.7
something is up here for sure with 1.7
We can be more dramatic about it:
In [5]: np.datetime64('1970-01-01T
On Tue, Apr 16, 2013 at 9:32 PM, Charles R Harris
wrote:
> Dude, it was the 60's, no one remembers.
I can't say I remember much from then -- but probably because I was 4
years old, not because of too much partying
-Chris
--
Christopher Barker, Ph.D.
Oceanographer
Emergency Response Div
On Tue, Apr 16, 2013 at 6:45 PM, Benjamin Root wrote:
>
> On Tue, Apr 16, 2013 at 7:45 PM, Ondřej Čertík wrote:
>
>> On Tue, Apr 16, 2013 at 4:55 PM, Bob Nnamtrop
>> wrote:
>> > I am curious if others have noticed an issue with datetime64 at the
>> > beginning of 1970. First:
>> >
>> > In [144]:
The problem does not appear to exist on Linux with numpy version 1.6.2.
In [1]: import numpy as np
In [2]: np.datetime64('1970-01-01') - np.datetime64('1969-12-31')
Out[2]: 1 day, 0:00:00
In [3]: np.datetime64('1970-01-01 00') - np.datetime64('1969-12-31 00')
Out[3]: 1 day, 0:00:00
In [4]: np._
On Tue, Apr 16, 2013 at 7:45 PM, Ondřej Čertík wrote:
> On Tue, Apr 16, 2013 at 4:55 PM, Bob Nnamtrop
> 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'))
> > Ou
On Tue, Apr 16, 2013 at 4:55 PM, Bob Nnamtrop 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
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
20 matches
Mail list logo