You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Something that has come up in the process of using xclim to calculate indices that are then fed to R is the incompatibilities of some calendars, specifically the notorious 360_day calendar. If non-standard calendars are not supported in the environment that uses this indicator data, problems ensue. While this is fine (users should be aware of calendar idiosyncrasies), I wonder if we could introduce a feature to make this a bit easier.
The specific case I want to address is when we perform a temporal aggregation (e.g. xclim.atmos.tg_mean(freq="MS")) with non-standard calendar data. Due to the way that the calendar is written (days since xxxx-yy-zz), we treat the first day of each month as the month itself. With non-standard calendars, this can lead to years in which we can see multiple values in a month or the slipping of dates backwards in time (especially with 360_day). None of this is new, and I don't suggest change this behaviour.
What I would like to see is a keyword in the calculations of indicators that allows for outputs to assume a standard calendar (ie: convert calendar being called). I understand that this already is triggered when performing ensemble analysis, but being able to change the calendar (called like xclim.atmos.some_indicator(freq="QS-DEC", to_calendar="proleptic_gregorian")) would make manual comparison of data much simpler.
The text was updated successfully, but these errors were encountered:
But adding this to the indicator call directly could be interesting, but I think we need to clean up the kwarg adding machinery before. Not much to do, just to decide on a clean way to inject those kwargs.
Something that has come up in the process of using xclim to calculate indices that are then fed to R is the incompatibilities of some calendars, specifically the notorious
360_day
calendar. If non-standard calendars are not supported in the environment that uses this indicator data, problems ensue. While this is fine (users should be aware of calendar idiosyncrasies), I wonder if we could introduce a feature to make this a bit easier.The specific case I want to address is when we perform a temporal aggregation (e.g.
xclim.atmos.tg_mean(freq="MS")
) with non-standard calendar data. Due to the way that the calendar is written (days since xxxx-yy-zz
), we treat the first day of each month as the month itself. With non-standard calendars, this can lead to years in which we can see multiple values in a month or the slipping of dates backwards in time (especially with360_day
). None of this is new, and I don't suggest change this behaviour.What I would like to see is a keyword in the calculations of indicators that allows for outputs to assume a standard calendar (ie: convert calendar being called). I understand that this already is triggered when performing
ensemble
analysis, but being able to change the calendar (called likexclim.atmos.some_indicator(freq="QS-DEC", to_calendar="proleptic_gregorian")
) would make manual comparison of data much simpler.The text was updated successfully, but these errors were encountered: