Hi Matti and Stefano,
My understanding is that datetime64 was decided to be neither TAI nor posix
time, but rather represent an abstract calendar point, like
datetime.datetime without a specified timezone. This can usually be
converted into posix time given a timezone (although in the "repeated" h
croseconds, 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
wr
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)
sn't do what it probably should:
>>> pd.Timestamp.now('UTC'), pd.Timestamp.now().tz_localize('UTC')
(Timestamp('2020-11-07 20:18:38.719603+', tz='UTC'),
Timestamp('2020-11-08 01:18:38.719701+', tz='UTC'))
(I have
r 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
> wrote:
>
>> Without weighing in yet on how I feel about
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')
:1: DeprecationWarning: parsing timezone aware datetimes is
deprecated; this will raise an error in the future
numpy
