[Numpy-discussion] Making datetime64 timezone naive

[Nathaniel Smith]

On Mon, Oct 12, 2015 at 12:10 AM, Stephan Hoyer <shoyer at gmail.com> wrote:
> As has come up repeatedly over the past few years, nobody seems to be very
> happy with the way that NumPy's datetime64 type parses and prints datetimes
> in local timezones.
>
> The tentative consensus from last year's discussion was that we should make
> datetime64 timezone naive, like the standard library's datetime.datetime:
> http://thread.gmane.org/gmane.comp.python.numeric.general/57184
>
> That makes sense to me, and it's exactly what I'd like to see happen for
> NumPy 1.11. Here's my PR to make that happen:
> https://github.com/numpy/numpy/pull/6453
>
> As a temporary measure, we still will parse datetimes that include a
> timezone specification by converting them to UTC, but will issue a
> DeprecationWarning. This is important for a smooth transition, because at
> the very least I suspect the "Z" modifier for UTC is widely used. Another
> option would be to preserve this conversion indefinitely, without any
> deprecation warning.

I'm dubious about supporting conversions in the long run -- even "Z"
-- because UTC datetimes and naive datetimes are really not the same
thing. OTOH maybe if we dropped this it would break everyone's code
and they would hate us -- I actually have no idea what people are
doing with datetime64 outside of pandas. One way to find out is to
start issuing DeprecationWarnings and see if anyone notices :-).
(Though of course this is far from fool-proof.)

> There's one (slightly) contentious API decision to make: What should we do
> with the numpy.datetime_to_string function? As far as I can tell, it was
> never documented as part of the NumPy API and has not been used very much or
> at all outside of NumPy's own test suite, but it is exposed in the main
> numpy namespace. If we can remove it, then we can delete and simplify a lot
> more code related to timezone parsing and display. If not, we'll need to do
> a bit of work so we can distinguish between the string representations of
> timezone naive and UTC.

One possible strategy here would be to do some corpus analysis to find
out whether anyone is actually using it, like I did for the ufunc ABI
stuff:
  https://github.com/njsmith/codetrawl
  https://github.com/njsmith/ufunc-abi-analysis

"datetime_to_string" is an easy token to search for, though it looks
like enough people have their own functions named that that you'd have
to do a bit of filtering to ignore non-numpy-related uses. A
filter("content", "import.*numpy") would collect all files that import
numpy into a single group for further examination.

-n

-- 
Nathaniel J. Smith -- http://vorpus.org