On Thu, Apr 4, 2013 at 12:52 AM, Chris Barker - NOAA Federal <chris.bar...@noaa.gov> wrote: > Thanks all for taking an interest. I need to think a bot more about > the options before commenting more, but: > > while we're at it: > > It seems very odd to me that datetime64 supports different units > (right down to attosecond) but not different epochs. How can it > possible be useful to use nanoseconds, etc, but only right around > 1970? For that matter, why all the units at all? I can see the need > for nanosecond resolution, but not without changing the epoch -- so if > the epoch is fixed, why bother with different units? Using days (for > instance) rather than seconds doesn't save memory, as we're always > using 64 bits. It can't be common to need more than 2.9e12 years (OK, > that's not quite as old as the universe, so some cosmologists may need > it...)
Another reason why it might be interesting to support different epochs is that many timeseries (e.g., the ones I work with) aren't linked to absolute time, but are instead "milliseconds since we turned on the recording equipment". You can reasonably represent these as timedeltas of course, but it'd be even more elegant to be able to be able to represent them as absolute times against an opaque epoch. In particular, when you have multiple recording tracks, only those which were recorded against the same epoch are actually commensurable -- trying to do recording1_times[10] - recording2_times[10] is meaningless and should be an error. I'm definitely not suggesting we go start retrofitting this into datetime64, but it's a real shame that defining a new dtype is so hard that we can't play around with such things on our own without serious mucking about in numpy's guts :-/. -n _______________________________________________ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion