A Wednesday 30 July 2008, Pierre GM escrigué:
> On Wednesday 30 July 2008 06:35:32 Francesc Alted wrote:
> > A Wednesday 30 July 2008, Ivan Vilata i Balaguer escrigué:
> > > Pierre GM (el 2008-07-29 a les 15:47:52 -0400) va dir::
> > > > On Tuesday 29 July 2008 15:14:13 Ivan Vilata i Balaguer wrote:
> > > > > Pierre GM (el 2008-07-29 a les 12:38:19 -0400) va dir::
>
> [Pierre]
>
> > > > Well, what about a .tounit(new_unit, reference=None) ?
> > > > By default, the reference would be None and default to the
> > > > POSIX epoch. We could also go for .totunit (for to time unit)
>
> [Ivan]
>
> > > Yes, that'd be the signature for a method.  The ``reference``
> > > argument shouldn't be allowed for ``datetime64`` values (absolute
> > > times, no ambiguities) but it should be mandatory for
> > > ``timedelta64`` ones. Sorry, but I can't see the use of having a
> > > default reference, unless one wanted to work with Epoch-based
> > > deltas, which looks like an extremely particular case.  Could you
> > > please show me a use case for having a reference defaulting to
> > > the POSIX epoch?
>
> [Francesc]
>
> > Yeah, I agree with Ivan in that a default reference time makes
> > little sense for general relative times.  IMO, and provided that we
> > will be allowing an implicit casting for most of time units for
> > relative vs relative and in absolute vs relative, the use of forced
> > casting will not be as frequent, and that a function would be
> > enough.  Having said that, I still see the merit of method for some
> > situations, so I'll mention that in the third proposal as a
> > possible improvement.
>
> In my mind, .tounit(*args) should be available for both relative
> (timedeltas) and absolute (datetime) times.

Well, what we are proposing is that the conversion time unit method for 
absolute times would be '.astype()' because its semantics is respected 
in this case.  The problem is with relative times, and only with 
conversions between years or months and the rest of time units.  This 
is why I propose the adoption of just a humble function for this cases.  
Introducing a method (.tounit()) for the ndarray object that only is 
useful for the date/time types seems a bit too much to my eyes (but I 
can be wrong, indeed).

> I agree that for relative 
> times, a default reference is meaningless. However, for absolute
> times, there's only one possible reference, the POSIX epoch, right ?

That's correct.

> Now, what format do you consider for this reference ?

Whatever that can be converted into a datetime64 scalar.  Some examples:

ref = '2001-04-01'
ref = datetime.datetime(2001, 4, 1)

> Moreover, could you give some more examples of interaction between
> datetime and timedelta ?

In the second proposal there are some examples of this interaction and 
I'm populating the third proposal with more examples yet.  Just wait a 
bit (maybe a couple of hours) to see the new proposal.

Cheers,

-- 
Francesc Alted
_______________________________________________
Numpy-discussion mailing list
Numpy-discussion@scipy.org
http://projects.scipy.org/mailman/listinfo/numpy-discussion

Reply via email to