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
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
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')) ==
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
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.