[Numpy-discussion] RFC: A proposal for implementing some date/time types in NumPy

Christopher Barker Chris.Barker@noaa....
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:
> ``datetime64``
>   - 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

very important!

>   Observations::
>     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 
written, however.

> * ``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 [11]: t[0] = datetime.datetime.now()  # setter in action
>   In [12]: t[0]
>   Out[12]: 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 
write, though.

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 mailing list