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 _______________________________________________ NumPy-Discussion mailing list [email protected] http://mail.scipy.org/mailman/listinfo/numpy-discussion
