[Numpy-discussion] NumPy date/time types and the resolution concept

[Francesc Alted]

A Tuesday 15 July 2008, Anne Archibald escrigué:
> 2008/7/15 Francesc Alted <faltet at pytables.org>:
> > Maybe is only that.  But by using the term 'frequency' I tend to
> > think that you are expecting to have one entry (observation) in
> > your array for each time 'tick' since time start.  OTOH, the term
> > 'resolution' doesn't have this implication, and only states the
> > precision of the timestamp.
> >
> > Well, after reading the mails from Chris and Anne, I think the best
> > is that the origin would be kept as an int64 with a resolution of
> > microseconds (for compatibility with the ``datetime`` module, as
> > I've said before).
>
> A couple of details worth pointing out: we don't need a zillion
> resolutions. One that's as good as the world time standards, and one
> that spans an adequate length of time should cover it. After all, the
> only reason for not using the highest available resolution is if you
> want to cover a larger range of times. So there is no real need for
> microseconds and milliseconds and seconds and days and weeks and...

Maybe you are right, but by providing many resolutions we are trying to 
cope with the needs of people that are using them a lot.  In 
particular, we are willing that the authors of the timseries scikit can 
find on these new dtype a fair replacement of their Date class (our 
proposal will be not so featured, but...).

> There is also no need for the origin to be kept with a resolution as
> high as microseconds; seconds would do just fine, since if necessary
> it can be interpreted as "exactly 7000 seconds after the epoch" even
> if you are using femtoseconds elsewhere.

Good point.  However, we finally managed to not include the ``origin`` 
metadata in our new proposal.  Have a look at the second proposal that 
I'll be posting soon for details.

Cheers,

-- 
Francesc Alted