Fixing non-second timedelta64 bug #1807
Conversation
This fixes #1738
|
Maybe updating - obs = pset.particledata.getvardata("obs_written", indices_to_write)
+ obs: list[int] = pset.particledata.getvardata("obs_written", indices_to_write)
Will fix mypy? |
parcels/tools/converters.py
Outdated
| self.time_origin = time_origin | ||
| self.calendar = "np_datetime64" | ||
| elif isinstance(time_origin, np.timedelta64): | ||
| self.time_origin = time_origin.astype("timedelta64[s]") |
There was a problem hiding this comment.
Is it a concern that this may lose subsecond resolution?
>>> np.timedelta64(110, "ns").astype('timedelta64[s]')
np.timedelta64(0,'s')
There was a problem hiding this comment.
Now using nanoseconds for timedelta64; better like this?
There was a problem hiding this comment.
I don't think so. The issue stems with the actual comparison of datetime objects in .reltime(). I'm not entirely sure what datetime objects are coming into (or expected to come into) that function, so something more sophisticated may be needed.
There was a problem hiding this comment.
OK is fine; then let's discuss in person. Or feel free to propose something else, if you want
|
Looking under the hood at xarray, I think that we can rely on xarray internals for this. edit: hmmm, this is in their private API though info |
|
I think looking at how xarray does it and adopting a similar approach would be a good way to go (though whether we want to do that before v4 is another matter - not sure if this bug is encountered in production) |
|
Not needed in v4 |
This fixes #1738