<div dir="ltr"><div>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.</div><div><br></div><div>The tentative consensus from last year's discussion was that we should make datetime64 timezone naive, like the standard library's datetime.datetime:</div><div><a href="http://thread.gmane.org/gmane.comp.python.numeric.general/57184">http://thread.gmane.org/gmane.comp.python.numeric.general/57184</a><br></div><div><br></div><div>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:</div><a href="https://github.com/numpy/numpy/pull/6453">https://github.com/numpy/numpy/pull/6453</a><br><div><br></div><div>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.</div><div><br></div><div>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.</div><div><br></div><div>Best,</div><div>Stephan</div><div><br></div><div><br></div></div>