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
A Tuesday 29 July 2008, Francesc Alted escrigué:
[snip]
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
A Saturday 26 July 2008, Matt Knox escrigué:
For this goal, we are proposing a decoupling of the date/time use
cases in two different groups:
1. A pure ``datetime`` dtype (absolute or relative) that would be
useful for timestamping purposes in general (i.e. registering
dates without a
Hi,
Sorry for the very long delay in commenting on this. 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
On Fri, Jul 25, 2008 at 8:22 PM, Matt Knox [EMAIL PROTECTED] wrote:
The automatic string parsing has been mentioned before, but it is a feature
I am personally very fond of. I use it all the time, and I suspect a lot of
people would like it very much if they used it. It's not suited for high
Francesc Alted (el 2008-07-16 a les 18:44:36 +0200) va dir::
After tons of excellent feedback received for our first proposal about
the date/time types in NumPy Ivan and me have had another brainstorming
session and ended with a new proposal for your consideration.
After re-reading the
Hi,
After tons of excellent feedback received for our first proposal about
the date/time types in NumPy Ivan and me have had another brainstorming
session and ended with a new proposal for your consideration.
While this one does not reap all and every of the suggestions you have
made, we
