[Numpy-discussion] RFC: A proposal for implementing some date/time types in NumPy
Fri Jul 11 11:56:31 CDT 2008
Francesc Alted wrote:
> We are planning to implement some date/time types for NumPy,
A couple questions/comments:
> - Expressed in microseconds since POSIX epoch (January 1, 1970).
> - Resolution: nanoseconds.
how is that possible? Is that a typo?
> This will be compatible with the Python ``datetime`` module
> This will be not be fully compatible with the Python ``datetime``
> module neither in terms of precision nor time-span. However,
> getters and setters will be provided for it (loosing precision or
> overflowing as needed).
How to you propose handling overflowing? Would it raise an exception?
Another option would be to have a version that stored the datetime in
two values: say two int64s or something (kind of like complex numbers
are handled). This would allow a long time span and nanosecond (or
finer) precision. I guess it would require a bunch of math code to be
> * ``timefloat64``
> - Resolution: 1 microsecond (for +-32 years from epoch) or 14 digits
> (for distant years from epoch). So the precision is *variable*.
I'm not sure this is that useful, exactly for that reason. What's the
motivation for it? I can see using a float for timedelta -- as, in
general, you'll need less precision the linger your time span, but
having precision depend on how far you happen to be from the epoch seems
risky (though for anything I do, it wouldn't matter in the least).
> Example of use
> In : t = datetime.datetime.now() # setter in action
> In : t
> Out: 733234384724 # representation as an int64 (scalar)
hmm - could it return a numpy.datetime object instead, rather than a
straight int64? I'd like to see a representation that is clearly datetime.
> About the ``mx.DateTime`` module
> In this document, the emphasis has been put in comparing the
> compatibility of future NumPy date/time types against the ``datetime``
> module that comes with Python. Should we consider the compatibility
> with mx.DateTime as well?
No. The whole point of python's standard datetime is to have a common
system with which to deal with date-time values -- it's too bad it
didn't come sooner, so that mx.DateTime could have been built on it, but
at this point, I think supporting the standard lib one is most important.
I couldn't find documentation (not quickly, anyway) of how the datetime
object stores its data internally, but it might be nice to support that
protocol directly -- maybe that would make for too much math code to
What about timedelta types?
My final thought is that while I see that different applications need
different properties, having multiple representations seems like it will
introduce a lot of maintenance, documentation and support issues. Maybe
a single, more complicated representation would be a better bet (like
using two ints, rather than one, to get both range and precision)
Thanks for working on this -- I think it will be a great addition to numpy!
Christopher Barker, Ph.D.
Emergency Response Division
NOAA/NOS/OR&R (206) 526-6959 voice
7600 Sand Point Way NE (206) 526-6329 fax
Seattle, WA 98115 (206) 526-6317 main reception
More information about the Numpy-discussion