[Numpy-discussion] Datetime again

[Charles R Harris]

On Thu, Jan 29, 2015 at 12:55 AM, Eric Firing <efiring at hawaii.edu> wrote:

> On 2015/01/28 6:29 PM, Charles R Harris wrote:
> >
> >
> >     And as for "The 64 bits of long long really isn't enough and leads
> >     to all sorts of compromises". not long enough for what? I've always
> >     thought that what we need is the ability to set the epoch. Does
> >     anyone ever need picoseconds since 100 years ago? And if they did,
> >     we'd be in a heck of a mess with leap seconds and all that anyway.
> >
> >
> > I was thinking elapsed time. Nanoseconds can be rather crude for that
> > depending on the measurement. Of course, such short times aren't going
> > to come from the system clock, but data collected in other ways,
> > interference between light pulses over microscopic distances for
> > instance. Such data is likely acquired as, or computed, from simple
> > numbers with a unit, which gets us back to the numpy version. But that
> > complicates the heck out of things when you want to start adding times
> > in different units.
>
> Chuck,
>
> For any kind of data like that, I fail to see why any special numpy time
> type is needed at all.  Wouldn't the user just keep elapsed time as a
> count, or floating point number, in whatever units the instrument spits
> out?  Why does it need to be treated in a different way from any other
> numeric data?  We don't have special types for length. It seems to me
> that numpy's present experimental datetime64 type has already fallen
> into the trap of overengineering--trying to be too many things to too
> many people.  The main reason for having a special datetime type is to
> deal with the calendar mess, and conventional hours-minutes-seconds
> time.  For very short time intervals, all that is irrelevant.
>

That's probably what it comes down to in practice. If we *had* quad
precision floats, it would be an easy solution, but we don't, so probably
the Blaze proposal with 64 bit integers and a fixed tick unit is the easy
way to go.

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