[Numpy-discussion] RFC: A (second) proposal for implementing some date/time types in NumPy
Tue Jul 29 03:48:35 CDT 2008
A Monday 28 July 2008, Christopher Barker escrigué:
> 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 : t = datetime.datetime.now() # setter in action
> > In : t
> > Out: '2008-07-16T13:39:25.315' # representation in ISO 8601
> I like that, but what about:
> > In : t1 = numpy.zeros(5, dtype="datetime64[s]")
> > In : t2 = numpy.ones(5, dtype="datetime64[s]")
> > In : t = t2 - t1
> > In : t = 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 = 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 = 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 : t
> > Out: 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
That could be an interesting feature. Here it is what the ``datetime``
>>> delta = datetime.datetime(1980,2,1)-datetime.datetime(1970,1,1)
'3683 days, 0:00:00'
For the NumPy ``timedelta64`` with a time unit of days, it could be
while for a ``timedelta64`` with a time unit of microseconds it could
'3683 days, 3:04:05.000064'
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?
More information about the Numpy-discussion