Open hmaarrfk opened 1 week ago
maybe related to https://github.com/pydata/xarray/issues/9399
Indeed, the changes in #9403 appear to fix this. However, I can only reproduce with
ds["timestamp"] = np.datetime64(datetime.now(UTC))
If instead I use
ds["timestamp"] = np.datetime64(datetime.now(UTC), "ns")
it doesn't fail. So this also depends on the units of the datetime64
object.
I've seen the "ns"
warning for a while
I'm having a hard time convincing myself that "ns"
is the right units.
>> 2 ** 63
9223372036854775808
maybe i'm just crazy though:
ns_per_year = (365 * 24 * 60 * 60 * 1E9)
2 ** 63 / ns_per_year
292.471208677536
and 292 years is fine if you consider the date starts from 1974. <-- is this true?
I think the timestamps should start from 1970-01-01 00:00:00
(as they're standard unix timestamps), so you're not far off with 1974. You can verify that with np.array([0]).astype("datetime64[ns]")
.
There have been requests to relax the restriction to "ns"
units for quite some time (following pandas
), and in general this should be possible but is quite a bit of work.
Right so the question is, do we care about the year 2262?
np.array([0, np.iinfo('int64').max]).astype("datetime64[ns]")
array(['1970-01-01T00:00:00.000000000', '2262-04-11T23:47:16.854775807'],
dtype='datetime64[ns]'
so i think i'm over thinking it for 2024 in my own code base, so I can start to sprinkle "ns"
within it to help with compatibility while you get that PR resolved.
What happened?
It seems that numpy 2.1 broke some type checking with datetime64 and now it makes it difficult to serialize them?
Oddly enough, you cannot recreate this with numpy 2.0. Only 2.1
What did you expect to happen?
for it to work ;)
Minimal Complete Verifiable Example
MVCE confirmation
Relevant log output
No response
Anything else we need to know?
Environment