Hi Nathaniel,
It differs by allowing time zone info to be preserved if supplied. A naive datetime64 would be unable to handle this, and would either have to ignore the tzinfo or would have to throw up an exception. The current suggestion is very similar to a naive datetime64 and only differs in being able to handle the given tzinfo, rather than ignoring it or telling the user that the current implementation cannot handle it.
This would be superioir to a naive dateime64 for use cases that have the tzinfo available, and would avoid the users having to workaround NumPy's inability to handle them if provided.
A big thanks to Chris Barker for the write up linked in the proposal, it makes it very clear what the various possibilities are for improvement.
Cheers,
Sankarshan
On Mar 20, 2014, at 7:16 AM, Nathaniel Smith <
njs@pobox.com> wrote:
On 20 Mar 2014 02:07, "Sankarshan Mudkavi" <smudkavi@uwaterloo.ca> wrote:
> I've written a rather rudimentary NEP, (lacking in technical details which I will hopefully add after some further discussion and receiving clarification/help on this thread).
>
> Please let me know how to proceed and what you think should be added to the current proposal (attached to this mail).
>
> Here is a rendered version of the same:
> https://github.com/Sankarshan-Mudkavi/numpy/blob/Enhance-datetime64/doc/neps/datetime-improvement-proposal.rst
Your NEP suggests making all datetime64s be in UTC, and treating string representations from unknown timezones as UTC. How does this differ from, and why is it superior to, making all datetime64s be naive?
-n
_______________________________________________
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
http://mail.scipy.org/mailman/listinfo/numpy-discussion
--
Sankarshan Mudkavi
Undergraduate in Physics, University of Waterloo