[Numpy-discussion] Proposal: add the timestamp64 type

[Noam Yorav-Raphael]

I added discussing my proposal to the upcoming meeting agenda.

I thought of a refinement. Since numpy data types don't have static
methods, instead of using "timestamp64.now()" it could be another function
of the constructor. So timestamp64() will return the current timestamp in
microseconds, and timestamp64('s'), timestamp64('ms'), timestamp64('us')
and timestamp64('ns') will return the current timestamp in the given unit.
This makes the interface even simpler!

Cheers,
Noam



On Sat, Nov 7, 2020 at 10:57 PM Noam Yorav-Raphael <noamraph at gmail.com>
wrote:

> 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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.python.org/pipermail/numpy-discussion/attachments/20201111/c0962657/attachment.html>