[Numpy-discussion] timezones and datetime64

[Nathaniel Smith]

On Thu, Apr 4, 2013 at 12:52 AM, Chris Barker - NOAA Federal
<chris.barker at 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