[Numpy-discussion] datetime64: Remove deprecation warning when constructing with timezone

[Stephan Hoyer]

I can try to dig up the old discussions, but datetime64 used to implement
both (1) and (3), and this was updated in a very intentional way.
Datetime64 now works like Python's own time-zone naive datetime.datetime
objects. The documentation referencing "Z" should be updated -- datetime64
can be in any timezone you like.

Timezone aware datetime objects are certainly useful, but NumPy's
datetime64 was restricted to UTC. The consensus was that it was worse to
have UTC-only rather than timezone-naive-only. NumPy's datetime64 is often
used for data analysis purposes, for which automatic conversion to the
local timezone of the computer running the analysis is often
counter-productive.

If you care about timezone conversions, I would highly recommend looking
into pandas's Timestamp class for this purpose. In the future, this would
be a good use-case for a new custom NumPy dtype. (The existing
np.datetime64 code cannot easily handle multiple timezones.)

On Thu, Nov 5, 2020 at 1:04 PM Eric Wieser <wieser.eric+numpy at gmail.com>
wrote:

> 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:
>
> https://github.com/numpy/numpy/pull/6453
>
> Eric
>
> On Thu, Nov 5, 2020, 20:13 Noam Yorav-Raphael <noamraph at gmail.com> wrote:
>
>> Hi,
>>
>> I suggest removing the deprecation warning when constructing a datetime64
>> with a timezone. For example, this is the current behavior:
>>
>> >>> np.datetime64('2020-11-05 16:00+0200')
>> <stdin>:1: DeprecationWarning: parsing timezone aware datetimes is
>> deprecated; this will raise an error in the future
>> numpy.datetime64('2020-11-05T14:00')
>>
>> 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').
>>
>> 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.
>>
>> So this is my simple suggestion: remove the deprecation warning.
>>
>>
>> Beyond that, I have 3 ideas for changing the repr of datetime64 that I
>> would like to discuss.
>>
>> 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.
>>
>> 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.
>>
>> 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:
>>
>> repr(np.datetime64('2020-11-05 14:00Z')) ==
>> "numpy.datetime64('2020-11-05T16:00+0200')"
>>
>> I'm sure the pros and cons of having an environment-dependent repr should
>> be discussed. But I will list some pros:
>> 1. It's very convenient - it's immediately obvious to me to which moment
>> 2020-11-05 16:00+0200 refers.
>> 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.
>> 3. It's very simple - I could compare any two timestamps, I don't have to
>> worry about time zones.
>>
>> I would be happy to hear your thoughts.
>>
>> Thanks,
>> Noam
>> _______________________________________________
>> NumPy-Discussion mailing list
>> NumPy-Discussion at python.org
>> https://mail.python.org/mailman/listinfo/numpy-discussion
>>
> _______________________________________________
> NumPy-Discussion mailing list
> NumPy-Discussion at python.org
> https://mail.python.org/mailman/listinfo/numpy-discussion
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.python.org/pipermail/numpy-discussion/attachments/20201105/82d70cde/attachment-0001.html>