[Numpy-discussion] fixing up datetime

Christopher Barker Chris.Barker@noaa....
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 
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:


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 mailing list