[Numpy-discussion] fixing up datetime

[Christopher Barker]

Dave Hirschfeld wrote:
> Robert Kern <robert.kern <at> gmail.com> writes:

>> Well, [D/100] doesn't represent [864s]. It represents something that
>> happens 100 times a day, but not necessarily at precise regular
>> intervals.

>> For example, suppose that I am representing payments that
>> happen twice a month, say on the 1st and 15th of every month, or the
>> 5th and 20th. I would use [M/2] to represent that. It's not [2W], and
>> it's not [15D]. It's twice a month.

Got it -- very useful concept, of course.

>> The default conversions may seem to imply that [D/100] is equivalent
>> to [864s], but they are not intended to. They are just a starting
>> point for one to write one's own, more specific conversions.

Here is my issue -- I don't think there should be default conversions at 
all -- as you point out, "twice a month" is a well defined concept, but 
it is NOT the same as every 15 days (or any other set interval). I'm not 
sure it should be possible to "convert" to a regular interval at all.

> That would be one way of dealing with irregularly spaced data. I would argue
> that the example is somewhat back-to-front though. If something happens
> twice a month it's not occuring at a monthly frequency, but at a higher
> frequency.

And that frequency is 2/month.

> In this case the lowest frequency which can capture this data is
> daily frequency so it should be stored at daily frequency

I don't think it should, because it isn't 1/15 days, or, indeed, an 
frequency that can be specified as days. Sure you can specify the 5th 
and 20th of each month in a given time span in terms of days since an 
epoch, but you've lost some information there. When you want to do math 
-- like add a certain number of 1/2 months -- when is the 100th payment 
due? It seems keeping it in M/2 is the most natural way to deal with 
that -- then you don't need special code to do that addition, only when 
converting to a string (or other format) datetime.

Anyway, my key point is that converting to/from calendar-based units and 
"linear time" units is fraught with peril -- it needs to be really clear 
when that is happening, and the user needs to have a clear and ideally 
easy way to define how it should happen.

-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

Chris.Barker at noaa.gov