Pandas 3.0 has changed the default datetime precision to microsecond, when I believe it was nanosecond previously:
https://pandas.pydata.org/docs/dev/whatsnew/v3.0.0.html#datetime-timedelta-resolution-inference
There are some places in the package where we specify nanosecond, which I assume was to conform to the previous pandas default precision:
|
def valuation(self): |
|
ddims = self.ddims |
|
if self.is_val_tri: |
|
out = pd.DataFrame(np.repeat(self.ddims.values[None], len(self.odims), 0)) |
|
return pd.DatetimeIndex(out.unstack().values) |
|
ddim_arr = ddims - ddims[0] |
|
origin = np.minimum(self.odims, np.datetime64(self.valuation_date)) |
|
val_array = origin.astype("datetime64[M]") + np.timedelta64(ddims[0], "M") |
|
val_array = val_array.astype("datetime64[ns]") - np.timedelta64(1, "ns") |
However this leads to a breaking change whenever we compare these datetimes to those generated from the default pandas conversions, which happens in the valuation == valuation_date comparison discovered by Henry, due to a nanosecond-to-microsecond comparison.
I propose that we adopt microsecond as the default datetime, to stay consistent with pandas.
Pandas 3.0 has changed the default datetime precision to microsecond, when I believe it was nanosecond previously:
https://pandas.pydata.org/docs/dev/whatsnew/v3.0.0.html#datetime-timedelta-resolution-inference
There are some places in the package where we specify nanosecond, which I assume was to conform to the previous pandas default precision:
chainladder-python/chainladder/core/base.py
Lines 535 to 543 in 6ea3577
However this leads to a breaking change whenever we compare these datetimes to those generated from the default pandas conversions, which happens in the
valuation == valuation_datecomparison discovered by Henry, due to a nanosecond-to-microsecond comparison.I propose that we adopt microsecond as the default datetime, to stay consistent with pandas.