<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Mon, Oct 12, 2015 at 12:38 AM, Nathaniel Smith <span dir="ltr"><<a href="mailto:njs@pobox.com" target="_blank">njs@pobox.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">> As a temporary measure, we still will parse datetimes that include a<br>
> timezone specification by converting them to UTC, but will issue a<br>
> DeprecationWarning. This is important for a smooth transition, because at<br>
> the very least I suspect the "Z" modifier for UTC is widely used. Another<br>
> option would be to preserve this conversion indefinitely, without any<br>
> deprecation warning.<br>
<br>
</span>I'm dubious about supporting conversions in the long run -- even "Z"<br>
-- because UTC datetimes and naive datetimes are really not the same<br>
thing.</blockquote><div><br></div><div>no -- but almost!</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"> OTOH maybe if we dropped this it would break everyone's code<br>
and they would hate us -- </blockquote><div><br></div><div>I think it probably would. In the current implementation, an ISO string without an offset specifier is converted using the system's locale timezone. So to get naive time (or UTC), we need to tack a Z (or 00:00) on there. </div><div><br></div><div>So killing that would likely break a lot of code!</div><div><br></div><div>And excepting a Z or 00:00 and then treating it as naive, while being perhaps misleading, would not actually change any results. So I say we keep it.</div><div><br></div><div>Depreciating it eventually would be good in the long run -- but maybe when we have actual time zone support.</div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">I actually have no idea what people are<br>
doing with datetime64 outside of pandas.</blockquote><div><br></div><div>What do we need to do with this not to break Panda? I'm guessing more people use datetime64 wrapped by Pandas than any other way...</div><div><br></div><div>(not me, though)</div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">> There's one (slightly) contentious API decision to make: What should we do<br>
> with the numpy.datetime_to_string function? As far as I can tell, it was<br>
> never documented as part of the NumPy API and has not been used very much </span></blockquote><div><br></div><div>Well, I'm not using it :-) though I can see that it might be pretty useful. Though once we get rid of datetime64 adjusting for the locale timezone, maybe not anymore.</div><div><br></div><div>-CHB</div><div> <br></div></div><div><br></div>-- <br><div class="gmail_signature"><br>Christopher Barker, Ph.D.<br>Oceanographer<br><br>Emergency Response Division<br>NOAA/NOS/OR&R            (206) 526-6959   voice<br>7600 Sand Point Way NE   (206) 526-6329   fax<br>Seattle, WA  98115       (206) 526-6317   main reception<br><br><a href="mailto:Chris.Barker@noaa.gov" target="_blank">Chris.Barker@noaa.gov</a></div>
</div></div>