Pierre GM wrote: >> 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,
Actually, I have little issue with weeks -- it can be clearly defined as 7 * 24 hours. The problem with months is that they are not all the same length. One of the issues pointed out in the discussion on the CF list was that for the most part, scientist expect that a time series has nice properties, like differentiability, etc. That all goes to heck if you have months as a unit. Unless a month is clearly defined as a particular number of hours, and ONLY means that, but then some folks may not get what they expect. > Anyhow, years and months are simple enough. no, they are not -- they are fundamentally different than hours, days, etc. > In case of ambiguities like Mark's example, we can always raise an exception. sure -- but what I'm suggesting is that rather than have one thing (a datetime array) that behaves differently according to what units it happens to use, we clearly separate what I'm calling Calendar functionality for basic time functionality. What that means to me is that a TimeDelta is ALWAYS an unambiguous time unit, and a datetime is ALWAYS expressed as an unambiguous time unit since a well-defined epoch. If you want something like "6 months after a datetime", or "14 business days after a datetime" that should be handles by a calendar class of some sort. (hmm, maybe I'm being too pedantic here -- the Calendar class could be associated with the datetime and timedelta objects, I suppose) so a given timedelta "knows" how to do math with itself. But I think this is fraught with problems: one of the keys to usability ond performance of the datetiem arrays is that they are really arrays of integers, and you can do math with them just as though they are integers. That will break if you allow these non-linear time steps. So, thinking out loud here, maybe: datetime timedelta calendartimedelta to make it very clear what one is working with? as for "calendardatetime", at first blush, I don't think there is a need. Do you need to express a datetime as "n months from the epoch", rather than "12:00am on July 1, 1970" -- which could be represented in hours, minutes, seconds, etc? What I'm getting at is that the difference between calendars is in what timedeltas mean, not what a unit in time is. > ISO8601 seems quite OK. All that does is specify a string representation, no? -Chris -- Christopher Barker, Ph.D. Oceanographer Emergency Response Division NOAA/NOS/OR&R (206) 526-6959 voice 7600 Sand Point Way NE (206) 526-6329 fax Seattle, WA 98115 (206) 526-6317 main reception [email protected] _______________________________________________ NumPy-Discussion mailing list [email protected] http://mail.scipy.org/mailman/listinfo/numpy-discussion
