Francesc Alted wrote: > We are planning to implement some date/time types for NumPy,
+1 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! -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 [EMAIL PROTECTED] _______________________________________________ Numpy-discussion mailing list Numpy-discussion@scipy.org http://projects.scipy.org/mailman/listinfo/numpy-discussion
