-
Notifications
You must be signed in to change notification settings - Fork 813
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[BUG] TimeSeries slicing silently changes the TimeSeries' frequency #2089
Comments
The problematic piece in the def _set_freq_in_xa(xa_: xr.DataArray):
# mutates the DataArray to make sure it contains the freq
if isinstance(xa_.get_index(self._time_dim), pd.DatetimeIndex):
inferred_freq = xa_.get_index(self._time_dim).inferred_freq
if inferred_freq is not None:
xa_.get_index(self._time_dim).freq = to_offset(inferred_freq)
else:
xa_.get_index(self._time_dim).freq = self._freq Always setting |
Hi @DavidKleindienst and thanks for raising this issue. I think we need to investigate a bit more on how to solve this, as we cannot set the frequency to the original one fore all cases of slicing:
Taking every second element from a daily frequency results in a 2 days frequency which is correct. |
Thank you @dennisbader for the quick response and explaing of the use case of the frequency inference. I'd be happy to contribute to fix this problem, but I'm not well aware of which use-cases require the inference. |
Describe the bug
When using BusinessDay as frequency, selecting a slice e.g. ts[1:5] can result in the slice having a different frequency (Day).
This is problematic because subsequent concatenations can fail because the two TimeSeries won't be contiguous at the altered frequency (but would be contiguous at the original frequency)
To Reproduce
Expected behavior
TimeSeries slicing should not silently alter the frequency
System (please complete the following information):
The text was updated successfully, but these errors were encountered: