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
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
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
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)
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 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
