[Numpy-discussion] NumPy date/time types and the resolution concept
Tue Jul 15 06:30:09 CDT 2008
A Monday 14 July 2008, Pierre GM escrigué:
> On Monday 14 July 2008 14:17:18 Francesc Alted wrote:
> > Well, what we are after is precisely this: a new dtype type. After
> > integrating it in NumPy, I suppose that your DateArray would be
> > similar than a NumPy array with a dtype ``datetime64`` (bar the
> > conceptual differences between your 'frequency' behind DateArray
> > and
> > the 'resolution' behind the datetime64 dtype).
> Well, you're losing me on this one: could you explain the difference
> between the two concepts ? It might only be a problem of
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
I don't know whether my impression is true or not, but after reading
about your TimeSeries package, I'm still thinking that this expectation
of one observation per 'tick' was what driven you to choose
the 'frequency' name.
> > It would start when the origin tells that it should start. It is
> > important to note that our proposal will not force a '7d' (seven
> > days) 'tick' to start on monday, or a '1m' (one month) to start the
> > 1st day of a calendar month, but rather where the user decides to
> > set its origin.
> OK, so we need 2 flags, one for the resolution, one for the origin.
> Because there won't be that many resolution possible, an int8 should
> be sufficient. What do you have in mind for the origin ? When using a
> resolution coarser than 1d (7d, 1m, 3m, 1a), an origin in day is OK.
> What about less than a day ?
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
More information about the Numpy-discussion