The usual rule is to deprecate before removing, and actual usage is more
important than docs. I agree that this function sounds like it should go,
but will keeping it around for a release or two allow scripts that
currently work right to keep working while we give people a smoother
transition off? Or will it just start immediately giving people incorrect
results?

In the process of making datetime64 time zone naive (#6453
#6453), I came across this function
that was added as part of datetime support, but that unfortunately @mwiebe
https://github.com/mwiebe never got around to documenting
https://mail.scipy.org/pipermail/numpy-discussion/2013-April/066084.html.
Nonetheless, it can of course be found in the wild
http://stackoverflow.com/questions/29616292/convertion-of-datetime-to-numpy-datetime-without-timezone-info
-- my github search also found a few snippets, though AFAICT it's not used
in any major projects.

The function provides the ability to print datetimes assumed to be
specified in UTC with different precision and time zones. See its unit tests

I could simply deprecate the timezone handling, but without timezone
handling it doesn't do very much. So I'm inclined to remove the entire
rarely used function. Given that it's not documented, do we need it to go
through a normal deprecation cycle?

cc @PythonCHB https://github.com/PythonCHB

—
Reply to this email directly or view it on GitHub
#7025.

@shoyer is there a serious gain of removing it (except removing dead code)? Do you need it removed to move forward with other things, or did the function break in some cases?
Otherwise I think I would just go with the safe side and deprecate it (or give it a VisibleDeprecationWarning just to annoy everyone more/warn people in case it is unreliable) for at least one release cycle.

The function still works properly, under the assumption that all naive datetimes are UTC. So I agree we can simply deprecate it without any harm. That's probably the safest path forward.

On Sat, Jan 16, 2016 at 1:34 AM, seberg [email protected] wrote:

@shoyer is there a serious gain of removing it (except removing dead code)? Do you need it removed to move forward with other things, or did the function break in some cases?

Otherwise I think I would just go with the safe side and deprecate it (or give it a VisibleDeprecationWarning just to annoy everyone more/warn people in case it is unreliable) for at least one release cycle.

Reply to this email directly or view it on GitHub:
#7025 (comment)

On Saturday, January 16, 2016, Stephan Hoyer [email protected]
wrote:

The function still works properly, under the assumption that all naive
datetimes are UTC.

Or the assumption that the datetime you call this function with is UTC.
It's a very common use case to use naive datetimes for UTC, so maybe this
is actually useful.

So I'd say the deprecation warning and see if anyone squawks ....

-CHB

Christopher Barker, PhD

Python Language Consulting

• Teaching
• Scientific Software Development
• Desktop GUI and Web Development
• wxPython, numpy, scipy, Cython

xref #17177 and #14243