[Numpy-discussion] The date/time dtype and the casting issue

Pierre GM pgmdevlist@gmail....
Tue Jul 29 11:38:19 CDT 2008

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...