Francesc,
Absolute time versus relative time ----------------------------------
We think that in this case the absolute time should have priority for determining the time unit of the outcome.
+1
Absolute time versus absolute time ----------------------------------
When operating (basically, only the substraction will be allowed) two absolute times with different unit times, we are proposing that the outcome would be to raise an exception.
+1 (However, I don't think that np.zeros(3, dtype="T8[Y]") is the most useful example ;))
Relative time versus relative time ----------------------------------
This case would be the same than the previous one (absolute vs absolute). Our proposal is to forbid this operation if the time units of the operands are different.
Mmh, less sure on this one. Can't we use a hierarchy of time units, and force to the lowest ? For example:
numpy.ones(3, dtype="t8[Y]") + 3*numpy.ones(3, dtype="t8[M]") array([15,15,15], dtype="t8['M']")
I agree that adding ns to years makes no sense, but ns to s ? min to hr or days ? In short: systematically raising an exception looks a bit too drastic. There are some simple unambiguous cases that sould be allowed (Y+M, Y+Q, M+Q, H+D...)
Introducing a time casting function -----------------------------------
change_unit(time_object, new_unit, reference)
where 'time_object' is the time object whose unit is to be changed, 'new_unit' is the desired new time unit, and 'reference' is an absolute date that will be used to allow the conversion of relative times in case of using time units with an uncertain number of smaller time units (relative years or months cannot be expressed in days).
reference default to the POSIX epoch, right ? So this function could be a first step towards our problem of frequency conversion...
Note: we refused to use the ``.astype()`` method because of the additional 'time_reference' parameter that will sound strange for other typical uses of ``.astype()``.
A method would be really, really helpful, though... Back to a previous email:
numpy.timedelta(20, unit='Y') + numpy.timedelta(365, unit='D') 20 # unit is Year
I would have expected days, or an exception (as there's an ambiguity in the length in days of a 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?
Gah, I dunno. Adding relative values is always tricky... I understand the last statement as 43 months and 31 days, which could be 44 months if we're speaking in months, or 3 years, 7 months, and 31 days...