[Numpy-discussion] fixing up datetime

[Charles R Harris]

On Thu, Jun 2, 2011 at 12:44 PM, Christopher Barker
<Chris.Barker at noaa.gov>wrote:

> 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.
>
>
>
I agree with the points that Chris is raising. And I would stick UTC in the
calender category on account of the leap seconds. That's not to say that
numpy shouldn't offer at least one 'calender' class, but that the
computational core needs to be kept flexible and not tie itself to something
like UTC that will in some circumstances require translation to linear
units. How to make that separation efficient is another question that
perhaps touches on labeled arrays, or arrays with units, or something in
that general category.

Chuck
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/numpy-discussion/attachments/20110602/f4fd2fcd/attachment.html>