# [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,

+1

> ``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.

> --------------------------------
>
> 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.

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!

-Chris

--
Christopher Barker, Ph.D.
Oceanographer

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

Chris.Barker@noaa.gov