<div dir="auto">Without weighing in yet on how I feel about the deprecation, you can see some discussion about why this was originally deprecated in the PR that introduced the warning:<div dir="auto"><br></div><div dir="auto"><a href="https://github.com/numpy/numpy/pull/6453">https://github.com/numpy/numpy/pull/6453</a><div dir="auto"><br></div><div dir="auto">Eric</div></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Thu, Nov 5, 2020, 20:13 Noam Yorav-Raphael <<a href="mailto:noamraph@gmail.com">noamraph@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">Hi,<div><br></div><div>I suggest removing the deprecation warning when constructing a datetime64 with a timezone. For example, this is the current behavior:</div><div><br></div><div>>>> np.datetime64('2020-11-05 16:00+0200')<br><stdin>:1: DeprecationWarning: parsing timezone aware datetimes is deprecated; this will raise an error in the future<br>numpy.datetime64('2020-11-05T14:00')<br></div><div><br></div><div>I suggest removing the deprecation warning because I find this to be a useful behavior, and because it is a correct behavior. The manual says: "The datetime object represents a single moment in time... Datetimes are always stored based on POSIX time, with an epoch of 1970-01-01T00:00Z." So 2020-11-05T16:00+0200 is indeed the moment in time represented by np.datetime64('2020-11-05T14:00').</div><div><br></div><div>I just used this to restrict my data set to records created after a certain moment. It was easier for me to write the moment in my local time and add "+0200" than to figure out the moment representation in UTC.</div><div><br></div><div>So this is my simple suggestion: remove the deprecation warning.</div><div><br></div><div><br></div><div>Beyond that, I have 3 ideas for changing the repr of datetime64 that I would like to discuss.</div><div><br></div><div>1. Add "Z" at the end, for example, numpy.datetime64('2020-11-05T14:00Z'). This will make it clear to which moment it refers. I think this is significant - I had to dig quite a bit to realize that datetime64('2020-11-05T14:00') means 14:00 UTC.</div><div><br></div><div>2. Replace the 'T' with a space. I just find it much easier to read '2020-11-05 14:00Z' than '2020-11-05T14:00Z'. The long sequence of characters makes it hard for my brain to parse.</div><div><br></div><div>3. This will require discussion, but will be very convenient: have the repr display the time using the environment time zone, including a time offset. So, in my specific time zone (+0200), I will have:</div><div><br></div><div>repr(np.datetime64('2020-11-05 14:00Z')) == "numpy.datetime64('2020-11-05T16:00+0200')"</div><div><br></div><div>I'm sure the pros and cons of having an environment-dependent repr should be discussed. But I will list some pros:</div><div>1. It's very convenient - it's immediately obvious to me to which moment 2020-11-05 16:00+0200 refers.</div><div>2. It's well defined - I may collect timestamps from machines with different time zones, and I will be able to know to which exact moment each timestamp refers.</div><div>3. It's very simple - I could compare any two timestamps, I don't have to worry about time zones.</div><div><br></div><div>I would be happy to hear your thoughts.</div><div><br></div><div>Thanks,</div><div>Noam</div></div>
_______________________________________________<br>
NumPy-Discussion mailing list<br>
<a href="mailto:NumPy-Discussion@python.org" target="_blank" rel="noreferrer">NumPy-Discussion@python.org</a><br>
<a href="https://mail.python.org/mailman/listinfo/numpy-discussion" rel="noreferrer noreferrer" target="_blank">https://mail.python.org/mailman/listinfo/numpy-discussion</a><br>
</blockquote></div>