[Numpy-discussion] RFC: A (second) proposal for implementing some date/time types in NumPy

Francesc Alted faltet at pytables.org
Tue Jul 29 04:48:35 EDT 2008


A Monday 28 July 2008, Christopher Barker escrigué:
> Hi,
>
> Sorry for the very long delay in commenting on this.

Don't worry, we are still in time to receive more comments (but if there 
is people willing to contribute more comments, hurry up, please!).

> In short, it 
> looks great, and thanks for your efforts.
>
> A couple small comments:
>  >  In [11]: t[0] = datetime.datetime.now()  # setter in action
>  >
>  >  In [12]: t[0]
>  >  Out[12]: '2008-07-16T13:39:25.315'   # representation in ISO 8601
>
> format
>
> I like that, but what about:
> >  In [8]: t1 = numpy.zeros(5, dtype="datetime64[s]")
> >  In [9]: t2 = numpy.ones(5, dtype="datetime64[s]")
> >
> >   In [10]: t = t2 - t1
> >
> >   In [11]: t[0] = 24  # setter in action (setting to 24 seconds)
>
> Is there a way to set in any other units? (hours, days, etc.)

Yes.  You will be able to use a scalar ``timedelta64``.  For example, if 
t is an array with dtype = 'timedelta64[s]' (i.e. with a time unit of 
seconds), you will be able to do the next:

>>> t[0] = numpy.timedelta64(2, unit="[D]") 

where you are adding 2 days to the 0-element of t.  However, you won't 
be able to do the next:

>>> t[0] = numpy.timedelta64(2, unit="[M]")

because a month has not a definite number of seconds.  This will 
typically raise a ``TypeError`` exception, or perhaps a 
``numpy.IncompatibleUnitError`` which would be more auto-explaining.

>
> >   In [12]: t[0]
> >   Out[12]: 24       # representation as an int64
>
> why not a "pretty" representation of timedelta64 too? I'd like that
> better (at least for __str__, perhaps __repr__ should be the raw
> numbers.

That could be an interesting feature.  Here it is what the ``datetime`` 
module does:

>>> delta = datetime.datetime(1980,2,1)-datetime.datetime(1970,1,1)
>>> delta.__str__()
'3683 days, 0:00:00'
>>> delta.__repr__()
'datetime.timedelta(3683)'

For the NumPy ``timedelta64`` with a time unit of days, it could be 
something like:

>>> delta_days.__str__()
'3683 days'
>>> delta_days.__repr__()
3683

while for a ``timedelta64`` with a time unit of microseconds it could 
be:

>>> delta_us.__str__()
'3683 days, 3:04:05.000064'
>>> delta_us.__repr__()
318222245000064

But I'm open to other suggestions, of course.

> how will operations between different types work?
>
>  > t1 = numpy.ones(5, dtype="timedelta64[s]")
>  > t2 = numpy.ones(5, dtype="timedelta64[ms]")
>
> t1 + t2
>
>  >> ??????

Yeah.  While the proposal stated that these operations should be 
possible, it is true that the casting rules where not stablished yet. 
After thinking a bit about this, we find that we should prioritize 
avoiding overflows rather than trying to keep the maximum precision.  
With this rule in mind, the outcome will always have the larger of the 
units in the operands.  In your example, t1 + t2 will have '[s]' units.

Would that make sense for most of people?

Cheers,

-- 
Francesc Alted



More information about the NumPy-Discussion mailing list