[Numpy-discussion] Datetime again

[Eric Firing]

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.

Eric