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

[Francesc Alted]

A Monday 28 July 2008, Pierre GM escrigué:
> On Monday 28 July 2008 12:17:41 Francesc Alted wrote:
> > So, for allowing this to happen, we have concluded that a
> > conceptual change in our second proposal is needed: instead of
> > a 'resolution', we can introduce the 'time unit' concept.
>
> I'm all for that, thanks !
>
> > One thing that will not be possible though, is
> > to change the time unit of a relative time expressed in say, years,
> > to another time unit expressed in say, days.  This is because the
> > impossibility to know how many days has a year that is relative
> > (i.e. not bound to a given year).
>
> OK, that makes sense for timedeltas. But would I still be able to add
> a timedelta['Y'] (in years) to a datetime['D'] (in days) and get the
> proper result ?

Hmmm, good point.  Well, provided that we plan to set the casting rules 
so that the time unit of the outcome will be the largest of the time 
units of the operands, and assuming aproximate values for the number of 
days in a year (365.2425, i.e. the average year length of the Gregorian 
calendar) and in a month (30.436875 = 365.2425/12), I think the next 
operations would be feasible:

>>> numpy.timedelta(20, unit='Y') + numpy.timedelta(365, unit='D')
20  # unit is Year
>>> numpy.timedelta(20, unit='Y') + numpy.timedelta(366, unit='D')
21  # unit is Year

>>> numpy.timedelta(43, unit='M') + numpy.timedelta(30, unit='D')
43  # unit is Month
>>> numpy.timedelta(43, unit='M') + numpy.timedelta(31, unit='D')
44  # unit is Month

Would that be ok for you?

> > More in general, it will not be possible
> > to perform 'time unit' conversions between units above and below a
> > relative week (because it is the maximum time unit that has a
> > definite number of seconds).
>
> Could you rephrase that ? You're still talking about conversion for
> timedelta, not datetime, right ?

Yes.  I was talking about the relative timedelta in that case.  The 
initial idea was to forbid conversions among relative timedeltas with 
different units that imply assumptions in the number of days.  But 
after largely pondering about the example above, I think now that it 
would be sensible to allow conversions from time units shorter than a 
week to larger than a week ones (but not the inverse), assuming the 
truncation of the outcome.  For example, the next would be allowed:

>>> numpy.timedelta(43, unit='D').astype("t8[M]")
1  # One complete month
>>> numpy.timedelta(365, unit='D').astype("t8[Y]")
0  # Not a complete year

But this would not:

>>> numpy.timedelta(2, unit='M').astype("t8[d]")
raise ``IncompatibleUnitError`` # How many days could have 2 months?
>>> numpy.timedelta(1, unit='Y').astype("t8[d]")
raise ``IncompatibleUnitError`` # How many days could have 1 year?

This will add more complexity to the code, but the functionality looks 
sensible to my eyes.  What do you think?

>
> > > >>>series.asfreq('A-MAR')
> >
> > Well, as we don't like an 'origin' to have part of our proposal,
> > you won't be able to do exactly that with the proposed plain dtype.
>
> That's what I was afraid of. Oh well, I'm sure we'll come with a
> way...
>
> Looking forward to reading the third version !

Well, as we are still discussing and changing things, we would like to 
wait a bit more until all the dust has settled.  But we are looking 
forward to produce the third version of the proposal before the end of 
this week.

Cheers,

-- 
Francesc Alted