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.
On Tue, Apr 16, 2013 at 4:55 PM, Bob Nnamtrop <bob.nnamtrop@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?
Indeed, this looks like a bug, I can reproduce it on linux as well: In [1]: import numpy as np In [2]: np.datetime64('1970-01-01') - np.datetime64('1969-12-31') Out[2]: numpy.timedelta64(1,'D') In [3]: np.datetime64('1970-01-01 00') - np.datetime64('1969-12-31 00') Out[3]: numpy.timedelta64(31,'h') In [4]: np.__version__ Out[4]: '1.7.1' We need to look into the sources to see what is going on. Ondrej
On Tue, Apr 16, 2013 at 7:45 PM, Ondřej Čertík <ondrej.certik@gmail.com>wrote:
On Tue, Apr 16, 2013 at 4:55 PM, Bob Nnamtrop <bob.nnamtrop@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?
Indeed, this looks like a bug, I can reproduce it on linux as well:
In [1]: import numpy as np
In [2]: np.datetime64('1970-01-01') - np.datetime64('1969-12-31') Out[2]: numpy.timedelta64(1,'D')
In [3]: np.datetime64('1970-01-01 00') - np.datetime64('1969-12-31 00') Out[3]: numpy.timedelta64(31,'h')
Maybe, maybe not... were you alive then? For all we know, Charles and co. were partying an extra 7 hours every day back then? Just sayin' Ben Root
On Tue, Apr 16, 2013 at 6:45 PM, Benjamin Root <ben.root@ou.edu> wrote:
On Tue, Apr 16, 2013 at 7:45 PM, Ondřej Čertík <ondrej.certik@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
On Tue, Apr 16, 2013 at 4:55 PM, Bob Nnamtrop <bob.nnamtrop@gmail.com> wrote: this a
bug?
Indeed, this looks like a bug, I can reproduce it on linux as well:
In [1]: import numpy as np
In [2]: np.datetime64('1970-01-01') - np.datetime64('1969-12-31') Out[2]: numpy.timedelta64(1,'D')
In [3]: np.datetime64('1970-01-01 00') - np.datetime64('1969-12-31 00') Out[3]: numpy.timedelta64(31,'h')
Maybe, maybe not... were you alive then? For all we know, Charles and co. were partying an extra 7 hours every day back then?
Dude, it was the 60's, no one remembers. Chuck
On Tue, Apr 16, 2013 at 9:32 PM, Charles R Harris <charlesr.harris@gmail.com> 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 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@noaa.gov
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.__version__ Out[4]: '1.6.2' Zach On Tue, Apr 16, 2013 at 4:45 PM, Ondřej Čertík <ondrej.certik@gmail.com>wrote:
On Tue, Apr 16, 2013 at 4:55 PM, Bob Nnamtrop <bob.nnamtrop@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?
Indeed, this looks like a bug, I can reproduce it on linux as well:
In [1]: import numpy as np
In [2]: np.datetime64('1970-01-01') - np.datetime64('1969-12-31') Out[2]: numpy.timedelta64(1,'D')
In [3]: np.datetime64('1970-01-01 00') - np.datetime64('1969-12-31 00') Out[3]: numpy.timedelta64(31,'h')
In [4]: np.__version__ Out[4]: '1.7.1'
We need to look into the sources to see what is going on.
Ondrej _______________________________________________ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
On Tue, Apr 16, 2013 at 8:23 PM, Zachary Ploskey <zploskey@gmail.com> 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-01T00') - np.datetime64('1969-12-31T23:59 ') Out[5]: numpy.timedelta64(481,'m') In [6]: np.datetime64('1970-01-01T00:00') - np.datetime64('1969-12-31T23:59 ') Out[6]: numpy.timedelta64(481,'m') 1970-01-01T00 is the epoch, of course, so no surprise that if there is something wrong, it would be there. Interesting that no one noticed this before -- I guess I haven't happened to use pre-1970 dates -- and or didn't check for accuracy down to a few hours... I'd say we need some more unit-tests! We've been discussion some changes to datetime64 anyway, so a good time to open it up. -CHris
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.__version__ Out[4]: '1.6.2'
Zach
On Tue, Apr 16, 2013 at 4:45 PM, Ondřej Čertík <ondrej.certik@gmail.com> wrote:
On Tue, Apr 16, 2013 at 4:55 PM, Bob Nnamtrop <bob.nnamtrop@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?
Indeed, this looks like a bug, I can reproduce it on linux as well:
In [1]: import numpy as np
In [2]: np.datetime64('1970-01-01') - np.datetime64('1969-12-31') Out[2]: numpy.timedelta64(1,'D')
In [3]: np.datetime64('1970-01-01 00') - np.datetime64('1969-12-31 00') Out[3]: numpy.timedelta64(31,'h')
In [4]: np.__version__ Out[4]: '1.7.1'
We need to look into the sources to see what is going on.
Ondrej _______________________________________________ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
_______________________________________________ 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.Barker@noaa.gov
On Wed, Apr 17, 2013 at 9:04 AM, Chris Barker - NOAA Federal <chris.barker@noaa.gov> wrote:
On Tue, Apr 16, 2013 at 8:23 PM, Zachary Ploskey <zploskey@gmail.com> 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/numpy/testing and https://github.com/numpy/numpy/tree/master/numpy/test but there's very little in there. -Chris -- 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@noaa.gov
On Wed, Apr 17, 2013 at 9:07 AM, Chris Barker - NOAA Federal <chris.barker@noaa.gov> 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 very little in there.
ah -- in another thread, Charles just pointed someone to: https://github.com/numpy/numpy/tree/master/numpy/core/tests so -- never mind. -Chris
-Chris
--
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@noaa.gov
-- 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@noaa.gov
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 <chris.barker@noaa.gov> wrote:
On Tue, Apr 16, 2013 at 8:23 PM, Zachary Ploskey <zploskey@gmail.com> 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/numpy/testing and https://github.com/numpy/numpy/tree/master/numpy/test
but there's very little in there.
The datetime is implemented in the core, so the tests are here: https://github.com/numpy/numpy/blob/master/numpy/core/tests/test_datetime.py - Sebastian
-Chris
On Wed, Apr 17, 2013 at 10:11 AM, Sebastian Berg <sebastian@sipsolutions.net> 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 <chris.barker@noaa.gov> wrote:
On Tue, Apr 16, 2013 at 8:23 PM, Zachary Ploskey <zploskey@gmail.com> 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/numpy/testing and https://github.com/numpy/numpy/tree/master/numpy/test
but there's very little in there.
The datetime is implemented in the core, so the tests are here:
https://github.com/numpy/numpy/blob/master/numpy/core/tests/test_datetime.py
I wonder if the problem has something to do with these functions here: https://github.com/numpy/numpy/blob/master/numpy/core/src/multiarray/datetim... https://github.com/numpy/numpy/blob/master/numpy/core/src/multiarray/datetim... Ondrej
On Tue, Apr 16, 2013 at 3:55 PM, Bob Nnamtrop <bob.nnamtrop@gmail.com> 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 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.
Indeed -- there are a couple other threads about DateTime64 right now, and we need to get a new NEP draft going (I've started discussion, but haven't had a chance to put it in a NEP yet...) It would be good to add this. How/Where do I start a NEP, anyway? It looks like they go here: https://github.com/numpy/numpy/tree/master/doc/neps But do I get it in pretty good shape first? Do I ask someone to commit it for me? -Chris
_______________________________________________ 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.Barker@noaa.gov
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') 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@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.
On Wed, Apr 17, 2013 at 2:09 PM, Bob Nnamtrop <bob.nnamtrop@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')
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.
I think you are right. The timezone conversion only happens for years >= 1970: https://github.com/numpy/numpy/blob/master/numpy/core/src/multiarray/datetim... Which explains the problem. Ondrej
On Wed, Apr 17, 2013 at 1:09 PM, Bob Nnamtrop <bob.nnamtrop@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.nnamtrop@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.Barker@noaa.gov
On Wed, Apr 17, 2013 at 7:10 PM, Chris Barker - NOAA Federal < chris.barker@noaa.gov> wrote:
On Wed, Apr 17, 2013 at 1:09 PM, Bob Nnamtrop <bob.nnamtrop@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')
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?)
Aren't we on standard time at Jan 1st? So, at that date, you would have been -8. Ben Root
On Wed, Apr 17, 2013 at 6:05 PM, Benjamin Root <ben.root@ou.edu> 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 (206) 526-6959 voice 7600 Sand Point Way NE (206) 526-6329 fax Seattle, WA 98115 (206) 526-6317 main reception Chris.Barker@noaa.gov
2013/4/18 Chris Barker - NOAA Federal <chris.barker@noaa.gov>
On Wed, Apr 17, 2013 at 1:09 PM, Bob Nnamtrop <bob.nnamtrop@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@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
see this at any other year. This discontinuity makes it hard to use the datetime64 object without special adjustment in ones code. I assume
don't 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.Barker@noaa.gov _______________________________________________ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
On Thu, Apr 18, 2013 at 2:27 AM, Joris Van den Bossche < jorisvandenbossche@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.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
Have you tried np.test()? I know some of the tests I added awhile back utilized pre-epoch dates to test sorting and min/max finding. Ben Root
On Wed, Apr 17, 2013 at 11:27 PM, Joris Van den Bossche <jorisvandenbossche@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.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
OK -- so that confirms the issue is from using the system libs to do this. though I'm surprised it fails on that date -- I would have expected it to fail on the 1960 date -- unless there is code that bypasses the system libs (Or modifies it some way) for pre-1970 dates.
We REALLY need to fix this!
There is a lot that we _could_ do to handle all tis well, but one thing is clear to me -- poor timezone support is MUCH worse than no timezone support! I'll get that NEP up, but I hope someone can get on this -- at least before any next release. -Chris -- 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@noaa.gov
participants (8)
-
Benjamin Root -
Bob Nnamtrop -
Charles R Harris -
Chris Barker - NOAA Federal -
Joris Van den Bossche -
Ondřej Čertík -
Sebastian Berg -
Zachary Ploskey