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
As we have discussed regarding custom reduction methods (#208), this indexing by year is too restrictive. I think we should replace it with a proper datetime object. This would enable using resample and groupby.
This is probably worth waiting until the cftime/netcdftime fixes upstream get incorporated. But I wanted to have this issue as a marker to make sure we don't forget this aspect of the output time types. @spencerkclark, any thoughts?
The text was updated successfully, but these errors were encountered:
I think this will largely be handled by adding functionality for custom reductions. Perhaps the default time reduction should be no reduction, as in #252 (which would maintain datetimes in the time coordinate in aospy output)?
Right now we always use groupby internally to convert data to a time series of annual means (this results in the 'year' coordinate of integer values), which is a totally valid reduction type, but perhaps not the most intuitive one for a default.
Currently, the time dimension of aospy output is simply 'year' and an integer. E.g. data outputted from our tutorial:
As we have discussed regarding custom reduction methods (#208), this indexing by year is too restrictive. I think we should replace it with a proper datetime object. This would enable using resample and groupby.
This is probably worth waiting until the
cftime
/netcdftime
fixes upstream get incorporated. But I wanted to have this issue as a marker to make sure we don't forget this aspect of the output time types. @spencerkclark, any thoughts?The text was updated successfully, but these errors were encountered: