[Numpy-discussion] datetime64

Fernando Perez fperez.net@gmail....
Thu Nov 19 16:40:04 CST 2009

Hi all,

On Thu, Oct 29, 2009 at 12:43 PM, Pierre GM <pgmdevlist@gmail.com> 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 allowing conversion from one frequency to
> another. Unfortunately, I don't think his work has been incorporated
> yet. Maybe Jarrod M. and Travis O. will shed some light on that
> matter. I for one would be quite interested into checking what's
> happening on that front.

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:

- It seems the original spec that was written by Francesc with a lot
of community feedback, whose final form (updated by Travis recently)


was implemented differently in the final committed code.  Are the
differences and rationale for this documented somewhere?  I'm not
saying the current code is a bad idea, simply that we'd like to
understand the differences and why they came about, I'm sure there
were good reasons behind it...

- Are there any tests for the current code, that will go in before 1.4
is out?  We'd like to know if we can rely on 1.4 as a dependency for
nitime, but for that we'd like to know what the code can actually do,
and also to have checks for what appear to be segfault problems:

>>> s = np.zeros((10),dtype=np.timedelta64)
>>> s
array([0:00:00.000001, 0:00:00.000001, 0:00:00.000001, 0:00:00.000001,
       0:00:00.000001, 0:00:00.000001, 0:00:00.000001, 0:00:00.000001,
       0:00:00.000001, 0:00:00.000001], dtype=timedelta64[ns])
>>> s.dtype = 'timedelta64[s]'
>>> s
array([0:01:00, 0:01:00, 0:01:00, 0:01:00, 0:01:00, 0:01:00, 0:01:00,
       0:01:00, 0:01:00, 0:01:00], dtype=timedelta64[s])
>>> s.dtype = 'timedelta64[m]'
Segmentation fault

- From our experimenting with the code it appears that the following
code is not accepted:

a = np.array([0.1, 0.5, 0.9, 1.4], dtype='some form of spelling
seconds, nothing we've tried has worked')

while it would appear to be a very natural way to use such an object:
"here are a bunch of floats, treat them like seconds"...  Is there a
reason for this?  This variant appears to work, but I'm not sure why
the need for the nested array call:

In [22]: a = np.array([0,0.1,0.5, 1.5]); a
Out[22]: array([ 0. ,  0.1,  0.5,  1.5])

In [23]: np.array(a, dtype='timedelta64[s]')
Out[23]: array([0:00:00, 0:00:00, 0:00:00, 0:01:00], dtype=timedelta64[s])

and the input is not being interpreted in seconds as one would
intuitively think, instead there's a truncation I'm not sure I

- I know that the name numpy.datetime() was in the spec above
(Francesc's NEP) but we're wondering if having this is a good idea...
This is a name clash with a stdlib python name that has existed for a
long time; while I know that we all advocate against 'from import *'
for many good reasons, but at least I think that staying clear of
known stdlib name conflicts would be a good practice.  It will reduce
the surprise factor for someone using numpy interactively, for example
(ipython -pylab) in situations like:

dateime.foo()  # this is  np.datetime
%run foo.py  # script with 'import datetime' in it
# now datetime at the top level is the one in the stdlib...

- Sources of information?  Docstrings and tests haven't gotten us very
far, and googling points to the original spec as udpated by Travis:


But even the examples in that document don't actually work.  All of
these copied from the spec, and run with:

In [7]: np.__version__
Out[7]: '1.4.0.dev7421'

In [2]: t = numpy.ones(3, dtype='M8[s]')
ValueError                                Traceback (most recent call last)

/home/fperez/teach/code_review/<ipython console> in <module>()

/usr/local/lib/python2.5/site-packages/numpy/core/numeric.pyc in
ones(shape, dtype, order)
   1656     a = empty(shape, dtype, order)
   1657     try:
-> 1658         a.fill(1)
   1659         # Above is faster now after addition of fast loops.
   1660         #a = zeros(shape, dtype, order)

ValueError: Must be a datetime.date or datetime.datetime object

In [5]: numpy.datetime64(42, 'us')
TypeError                                 Traceback (most recent call last)

/home/fperez/teach/code_review/<ipython console> in <module>()

TypeError: function takes at most 1 argument (2 given)

In [6]: numpy.timedelta64(10, 'us')
TypeError                                 Traceback (most recent call last)

/home/fperez/teach/code_review/<ipython console> in <module>()

TypeError: function takes at most 1 argument (2 given)

Thanks for any clarity on the status of this code... Sorry if we've
missed the obvious, but we've honestly tried to find information and
to understand this, and we're pretty lost.  Any help will be



More information about the NumPy-Discussion mailing list