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

Francesc Alted faltet@pytables....
Thu Jul 31 13:15:19 CDT 2008

A Thursday 31 July 2008, Alan G Isaac escrigué:
> > 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.
> On Thu, 31 Jul 2008, Francesc Alted apparently wrote:
> > 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.
> Quarterly frequency is probably the most analyzed frequency
> in macroeconometrics.
> Widely used macroeconometrics  packages (e.g., EViews)
> traditionally support only three explicit frequencies:
> annual, quarterly, and monthly.

I see.  However, I forgot to mention that another reason for not 
including the quarters is that they normally need flexibility to be 
defined as starting in *any* month of the year.  As we don't wanted to 
provide an ``origin`` metadata in the proposal (things got too complex 
already, as you can see in the third proposal that I sent to this list 
yesterday), then the usefulness of such an 'unflexible' quarters would 
be rather limited.  So, in the end, I think it is best to avoid them 
for the dtype (and add support for them in the ``Date`` class).


Francesc Alted

More information about the Numpy-discussion mailing list