On Jun 2, 2011, at 6:57 PM, Christopher Barker wrote: > Mark Wiebe wrote: >> I'm following what I understand the NEP to mean for combining dates and >> deltas of different units. This means for timedeltas, the metadata >> becomes more precise, in particular it becomes the GCD of the input >> metadata, and between timedelta and datetime the datetime always dominates. >> >> https://github.com/numpy/numpy/blob/master/doc/neps/datetime-proposal.rst > > Thanks for posting this link -- a few comments on that doc follow. > >> Only Years, Months, and Business Days have a nonlinear relationship with >> the other units, so they're the only problem case for this. They can be >> arbitrarily special-cased based on what is decided to make the most sense. > > As mentioned on my recent post -- this stuff should be handles by some > sort of "calendar" classes -- there is no one way to do that! So numpy > should provide datetime and timedelta data types that can be used, but a > timedelta should _not_ ever be defined by these weird variable units. > About the NEP: > > """ > 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. > If we're > going to allow different units, we might as well have different "origins". +1 > > 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: -1 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. 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 [email protected] http://mail.scipy.org/mailman/listinfo/numpy-discussion
