Dave Hirschfeld gmail.com> writes:
> The example below demonstrates the fact that the datetime64
> constructor ignores the dtype argument if passed in. Is this
> conscious design decision or a bug/oversight?
Bug. There's probably no dtype argument, but the constructor
just ignores all arguments:
The example below demonstrates the fact that the datetime64 constructor
ignores the dtype argument if passed in. Is this conscious design decision or
a bug/oversight?
In [55]: from datetime import datetime
...: d = datetime.now()
...:
In [56]: d
Out[56]: datetime.datetime(2013, 6, 12,
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
That makes sense.
I figured that ambiguity was the reason it was removed.
Thank you for the explanation. I'm a big fan of your work.
John
On Mon, Feb 6, 2012 at 1:18 PM, Mark Wiebe wrote:
> Hey John,
>
> NumPy doesn't provide this, because it's already provided by the
> datetime.date.strftime
Hey John,
NumPy doesn't provide this, because it's already provided by the
datetime.date.strftime function in Python:
http://docs.python.org/library/datetime.html#datetime.date.strftime
One reason this format isn't supported automatically is that parsing
"MM/dd/YY" is inherently ambiguous, and t
Hello,
Is there a way to specify a format for the datetime64 constructor? The
constructor doesn't have a doc. I have dates in a file with the format
"MM/dd/YY". datetime64 used to be able to parse these in 1.6.1 but the dev
version throws an error.
Cheers,
John
___
On Sun, Sep 18, 2011 at 8:52 PM, wrote:
> On Sun, Sep 18, 2011 at 11:13 PM, Charles R Harris
> wrote:
> >
> >
> > On Sun, Sep 18, 2011 at 9:08 PM, Charles R Harris
> > wrote:
> >>
> >>
> >> On Sun, Sep 18, 2011 at 6:32 PM, Benjamin Root wrote:
> >>>
> >>> I was working on adding some test case
On Sun, Sep 18, 2011 at 11:13 PM, Charles R Harris
wrote:
>
>
> On Sun, Sep 18, 2011 at 9:08 PM, Charles R Harris
> wrote:
>>
>>
>> On Sun, Sep 18, 2011 at 6:32 PM, Benjamin Root wrote:
>>>
>>> I was working on adding some test cases in numpy for the argmin/max
>>> functions with some datetime64
On Sunday, September 18, 2011, Charles R Harris
wrote:
>
>
> On Sun, Sep 18, 2011 at 6:32 PM, Benjamin Root wrote:
>>
>> I was working on adding some test cases in numpy for the argmin/max
functions with some datetime64s. I found that on my 32-bit machine, it
fails to parse a date past the Y2.03
On Sun, Sep 18, 2011 at 9:08 PM, Charles R Harris wrote:
>
>
> On Sun, Sep 18, 2011 at 6:32 PM, Benjamin Root wrote:
>
>> I was working on adding some test cases in numpy for the argmin/max
>> functions with some datetime64s. I found that on my 32-bit machine, it
>> fails to parse a date past t
On Sun, Sep 18, 2011 at 6:32 PM, Benjamin Root wrote:
> I was working on adding some test cases in numpy for the argmin/max
> functions with some datetime64s. I found that on my 32-bit machine, it
> fails to parse a date past the Y2.038k date. I find this odd because the
> datetime is supposed
I was working on adding some test cases in numpy for the argmin/max
functions with some datetime64s. I found that on my 32-bit machine, it
fails to parse a date past the Y2.038k date. I find this odd because the
datetime is supposed to be 64-bits, but I guess there is some arch-dependent
code som
Hi Travis,
[...]
On Thu, Nov 19, 2009 at 10:03 PM, Travis Oliphant
wrote:
> Again, the NEP has not been fully implemented yet. What is implemented
> works as far as I can tell, but could use more tests. I would like to
> finish the core functionality before 1.4.0 and will try to do that, but
we're starting to use these tools more and more, and with the 1.4
release coming out, we're a bit lost here... A few specific questions
we have:
The short answer to all of the questions is that datetime is not done
yet. Robert and I worked on the underlying framework so that it
could be
On Thu, Nov 19, 2009 at 6:47 PM, David Cournapeau wrote:
> On Fri, Nov 20, 2009 at 8:25 AM, Pierre GM wrote:
> >
> > On Nov 19, 2009, at 5:40 PM, Fernando Perez wrote:
> >>
> >> we're starting to use these tools more and more, and with the 1.4
> >> release coming out, we're a bit lost here...
> >
--
(mobile phone of)
Travis Oliphant
Enthought, Inc.
1-512-536-1057
http://www.enthought.com
On Nov 19, 2009, at 7:47 PM, David Cournapeau
wrote:
> On Fri, Nov 20, 2009 at 8:25 AM, Pierre GM
> wrote:
>>
>> On Nov 19, 2009, at 5:40 PM, Fernando Perez wrote:
>>>
>>> we're starting to use th
On Fri, Nov 20, 2009 at 8:25 AM, Pierre GM wrote:
>
> On Nov 19, 2009, at 5:40 PM, Fernando Perez wrote:
>>
>> we're starting to use these tools more and more, and with the 1.4
>> release coming out, we're a bit lost here...
>
> Welcome to the club...
> Fernando, Ariel, I'm in the same spot as you
On Nov 19, 2009, at 5:40 PM, Fernando Perez wrote:
>
> we're starting to use these tools more and more, and with the 1.4
> release coming out, we're a bit lost here...
Welcome to the club...
Fernando, Ariel, I'm in the same spot as you are, I haven't been able to use
it. I don't think it's tha
Hi all,
On Thu, Oct 29, 2009 at 12:43 PM, Pierre GM wrote:
> Oh yes, I saw that... Marty Fuhry, one of our GSoC students, had
> written some pretty extensive series of tests to allocate datetime/
> strings to elements of a ndarray with datetime64 dtype. He also had
> written some functions allowi
On Oct 29, 2009, at 4:22 PM, Alok Singhal wrote:
> Hi,
>
> On 29/10/09: 12:18, Ariel Rokem wrote:
>> I want to start trying out the new dtype for representation of arrays
>> of times, datetime64, which is implemented in the current svn. Is
>> there any documentation anywhere? I know of this propo
Hi,
On 29/10/09: 12:18, Ariel Rokem wrote:
> I want to start trying out the new dtype for representation of arrays
> of times, datetime64, which is implemented in the current svn. Is
> there any documentation anywhere? I know of this proposal:
>
> http://numpy.scipy.org/svn/numpy/tags/1.3.0/doc/n
Hi -
I want to start trying out the new dtype for representation of arrays
of times, datetime64, which is implemented in the current svn. Is
there any documentation anywhere? I know of this proposal:
http://numpy.scipy.org/svn/numpy/tags/1.3.0/doc/neps/datetime-proposal3.rst
but apparently the c
41 matches
Mail list logo
