[Numpy-discussion] fixing up datetime
Thu Jun 2 13:44:39 CDT 2011
On Thu, Jun 2, 2011 at 1:09 PM, Pierre GM <firstname.lastname@example.org> wrote:
> > """
> > A representation is also supported such that the stored date-time
> > integer can encode both the number of a particular unit as well as a
> > number of sequential events tracked for each unit.
> > """
> > I'm not sure I understand what this really means, but I _think_ I agree
> > with Pierre that this is unnecessary complication - couldn't it be
> > handled by multiple arrays, or maybe a structured dtype?
> My point. Mark W., perhaps you should ask the folks at Enthought (Travis O.
> in particular) what they had in mind ? Whether the original interest is
> still there. If it is, I wonder we can't find some workaround that would
> drop support for that.
I'll ask, for sure.
> > If we're
> > going to allow different units, we might as well have different
> > I also don't think that units like "month", "year", "business day"
> > should be allowed -- it just adds confusion. It's not a killer if they
> > are defined in the spec:
> In scikits.timeseries, not only did we have years,months and business days,
> but we also had weeks, that proved quite useful sometimes, and that were
> discarded in the discussion of the new NEP a few years back.
There are weeks in the implementation. One of my points in the original
email was whether to adjust week's epoch by a few days so they align with
ISO8601 weeks, do you have an opinion about that?
> Anyhow, years and months are simple enough. In case of ambiguities like
> Mark's example, we can always raise an exception. ISO8601 seems quite OK.
> Support for multiple time zones, daylight saving conventions, holidays and
> so forth could be let to specific packages.
> NumPy-Discussion mailing list
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the NumPy-Discussion