[Numpy-discussion] fixing up datetime
Thu Jun 2 13:44:07 CDT 2011
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
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
(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:
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?
Christopher Barker, Ph.D.
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
More information about the NumPy-Discussion