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

[Francesc Alted]

A Thursday 31 July 2008, Matt Knox escrigué:
> While on the topic of FAME... being a financial analyst, I really am
> quite fond of the multitude of quarterly frequencies we have in the
> timeseries package (with different year end points) because they are
> very useful when doing things like "calenderizing" earnings from
> companies with different fiscal year ends. These frequencies are
> included in FAME, which makes sense since it targets financial users.
> I know Pierre likes them too for working with different seasons. I
> think it would be ok to leave them out of an initial implementation,
> but it might be worth keeping in mind during the design phase about
> how the dtype could be extended to incorporate such things.

Well, introducing a quarter should not be difficult.  We just wanted to 
keep the set of supported time units under a minimum (the list is 
already quite large).  We thought that the quarter fits better as 
a 'derived' time unit, similarly as biweekly, semester or biyearly (to 
name just a few examples).  However, if quarters are found to be much 
more important than other derived time units, they can go into the 
proposal too.

> >> As forbidding operations among absolute/absolute and
> >> relative/relative types can be unacceptable in many situations, we
> >> are proposing an explicit casting mechanism so that the user can
> >> inform about the desired time unit of the outcome.  For this, a
> >> new NumPy function, called, say, ``numpy.change_unit()`` (this
> >> name is for the purposes of the discussion and can be changed)
> >> will be provided.  The signature for the function will be:
> >>
> >> 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).  For
> >>
> >> example, that would allow to do:
> >> >>> numpy.change_unit( numpy.array([1,2], 'T[Y]'), 'T[d]' )
> >>
> >> array([365, 731], dtype="datetime64[d]")
>
> If I understand you correctly, this is very close to the "asfreq"
> method of the Date/DateArray/TimeSeries classes in the timeseries
> module. One key element missing here (from my point of view anyway)
> is an equivalent of the 'relation' parameter in the asfreq method in
> the timeseries module. This is only used when converting from a lower
> frequency to a higher frequency (eg. annual to daily). For example...
>
> >>> a = ts.Date(freq='Annual', year=2007)
> >>> a.asfreq('Daily', 'START')
>
> <D : 01-Jan-2007>
>
> >>> a.asfreq('Daily', 'END')
>
> <D : 31-Dec-2007>
>
> This is another one of those things that I use all the time. Now
> whether it belongs in the core dtype, or some extension module I'm
> not sure... but it's an important feature in the timeseries module.

I agree that such a 'relation' parameter in the 
proposed 'change_timeunit' could be handy in many situations.  It 
should be applicable only to absolute times though.  With this, the 
signature for the function would be:

change_timeunit(time_object, new_unit, relation, reference)

where 'relation' only can be used with absolute times and 'reference' 
only with relative times.

Who knows, perhaps in the future one can find a way to implement such 
a 'change_timeunit' function as methods without disturbing too much the 
method schema of the ndarray objects.

Cheers,

-- 
Francesc Alted