[Numpy-discussion] The date/time dtype and the casting issue
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).
More information about the Numpy-discussion