On Mon, Oct 12, 2015 at 12:10 AM, Stephan Hoyer <sho...@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 _______________________________________________ NumPy-Discussion mailing list NumPy-Discussion@scipy.org https://mail.scipy.org/mailman/listinfo/numpy-discussion
