Hi,
(I'm repeating things I wrote under the "datetime64: Remove deprecation
warning..." thread, since I'm now proposing a new solution.)
I propose to add a new type called "timestamp64". It will be a pure
timestamp, meaning that it represents a moment in time (as seconds/ms/us/ns
since the epoch), without any timezone information. It will have the exact
same behavior as datetime64 had before version 1.11, except that its only
allowed units will be seconds, milliseconds, microseconds and nanoseconds.
Removing the longer units will make it clear that it doesn't deal with
calendar and dates. Also, all the business day functionality will not be
applicable to timestamp64. In order to get calendar information (such as
the year) from timestamp64, you will have to manually convert it to
python's datetime (or perhaps to np.datetime64) with an explicit timezone
(utc, local, an offset, or a timezone object).
This is needed because since the change introduced in 1.11, datetime64 no
longer represents a timestamp, but rather a date and time of an abstract
calendar. So given a datetime64, it is not possible to get an actual
timestamp without knowing the timezone to which the datetime64 refers. If
the datetime64 is in a timezone with daylight saving time, it can even be
ambiguous, since the same written hour will occur twice on the transition
from DST to winter time.
I would like it to work like this:
>>> np.timestamp64.now()
numpy.timestamp64('2020-11-07 22:42:52.871159+0200')
>>> np.timestamp64.now('s')
numpy.timestamp64('2020-11-07 22:42:52+0200')
>>> np.timestamp64(1604781916, 's')
numpy.timestamp64('2020-11-07 22:42:52+0200')
>>> np.timestamp64('2020-11-07 20:42:52Z')
numpy.timestamp64('2020-11-07 22:42:52+0200')
* timestamp64.now() will get an optional string argument with the base
units. If not given, I think 'us' is a good default.
* The repr will format the timestamp using the environment's timezone.
* I like the repr to not include a 'T' between the date and the time. I
find it much easier to read.
* I tend to think that it should be allowed to construct a timestamp64 from
an ISO8601 string without a timezone offset, in which case the
environment's timezone will be used to convert it to a timestamp. So in the
Asia/Jerusalem timezone it will look like:
>>> np.timestamp64('2020-11-07 22:42:52')
numpy.timestamp64('2020-11-07 22:42:52+0200')
>>> np.timestamp64('2020-08-01 22:00:00')
numpy.timestamp64('2020-08-01 22:00:00+0300')
If I implement this, could it be added to numpy?
Thanks,
Noam
_______________________________________________
NumPy-Discussion mailing list
NumPy-Discussion@python.org
https://mail.python.org/mailman/listinfo/numpy-discussion
