id,node_id,number,title,user,state,locked,assignee,milestone,comments,created_at,updated_at,closed_at,author_association,active_lock_reason,draft,pull_request,body,reactions,performed_via_github_app,state_reason,repo,type 857947050,MDU6SXNzdWU4NTc5NDcwNTA=,5155,Calendar utilities,20629530,closed,0,,,9,2021-04-14T14:18:48Z,2021-12-30T22:54:11Z,2021-12-30T22:54:11Z,CONTRIBUTOR,,,,"**Is your feature request related to a problem? Please describe.** Handling cftime and numpy time coordinates can sometimes be exhausting. Here I am thinking of the following common problems: 1. Querying the calendar type from a time coordinate. 2. Converting a _dataset_ from a calendar type to another. 3. Generating a time coordinate in the correct calendar. **Describe the solution you'd like** 1. `ds.time.dt.calendar` would be magic. 2. `xr.convert_calendar(ds, ""new_cal"")` could be nice? 3. `xr.date_range(start, stop, calendar=cal)`, same as pandas' (see context below). **Describe alternatives you've considered** We have implemented all this in (xclim)[https://xclim.readthedocs.io/en/stable/api.html#calendar-handling-utilities] (and more). But it seems to make sense that some of the simplest things there could move to xarray? We had this discussion in xarray-contrib/cf-xarray#193 and suggestion was made to see what fits here before implementing this there. **Additional context** At xclim, to differentiate numpy datetime64 from cftime types, we call the former ""default"". This way a time coordinate using cftime's ""proleptic_gregorian"" calendar is distinct from one using numpy's datetime64. 1. is easy ([xclim function](https://xclim.readthedocs.io/en/stable/api.html#xclim.core.calendar.get_calendar)). If the datatype is numpy return ""default"", if cftime, look into the first non-null value and get the calendar. 2. [xclim function](https://xclim.readthedocs.io/en/stable/api.html#xclim.core.calendar.convert_calendar) The calendar type of each time element is transformed to the new calendar. Our way is to _drop_ any dates that do not exist in the new calendar (like Feb 29th when going to ""noleap""). In the other direction, there is an option to either fill with some fill value of simply _not_ include them. It can't be a DataArray method, but could be a Dataset one, or simply a top-level function. Related to #5107. We also have an [`interp_calendar`](https://xclim.readthedocs.io/en/stable/api.html#xclim.core.calendar.interp_calendar) function that reinterps data on a yearly basis. This is a bit narrower, because it only makes sense on daily data (or coarser). 3. With the definition of a ""default"" calendar, [`date_range`](https://xclim.readthedocs.io/en/stable/api.html#xclim.core.calendar.date_range) and `date_range_like` simply chose between `pd.date_range` and `xr.cftime_range` according to the target calendar. What do you think? I have time to move whatever code makes sense to move.","{""url"": ""https://api.github.com/repos/pydata/xarray/issues/5155/reactions"", ""total_count"": 0, ""+1"": 0, ""-1"": 0, ""laugh"": 0, ""hooray"": 0, ""confused"": 0, ""heart"": 0, ""rocket"": 0, ""eyes"": 0}",,completed,13221727,issue 557627188,MDExOlB1bGxSZXF1ZXN0MzY5MTg0Mjk0,3733,Implementation of polyfit and polyval,20629530,closed,0,,,9,2020-01-30T16:58:51Z,2020-03-26T00:22:17Z,2020-03-25T17:17:45Z,CONTRIBUTOR,,0,pydata/xarray/pulls/3733," - [x] Closes #3349 - [x] Tests added - [x] Passes `isort -rc . && black . && mypy . && flake8` - [x] Fully documented, including `whats-new.rst` for all changes and `api.rst` for new API Following discussions in #3349, I suggest here an implementation of `polyfit` and `polyval` for xarray. However, this is still work in progress, a lot of testing is missing, all docstrings are missing. But, mainly, I have questions on how to properly conduct this. My implementation mostly duplicates the code of `np.polyfit`, but making use of `dask.array.linalg.lstsq` and `dask.array.apply_along_axis` for dask arrays. The same method as in `xscale.signal.fitting.polyfit`, but I add NaN-awareness in a 1-D manner. The version with numpy is also slightly different of `np.polyfit` because of the NaN skipping, but I wanted the function to replicate its behaviour. It returns a variable number of DataArrays, depending on the keyword arguments (coefficients, [ residuals, matrix rank, singular values ] / [covariance matrix]). Thus giving a medium-length function that has a lot of duplicated code from `numpy.polyfit`. I thought of simply using a `xr.apply_ufunc`, but that makes chunking along the fitted dimension forbidden and difficult to return the ancillary results (residuals, rank, covariance matrix...). Questions: 1 ) Are the functions where they should go? 2 ) Should xarray's implementation really replicate the behaviour of numpy's? A lot of extra code could be removed if we'd say we only want to compute and return the residuals and the coefficients. All the other variables are a few lines of code away for the user that really wants them, and they don't need the power of xarray and dask anyway.","{""url"": ""https://api.github.com/repos/pydata/xarray/issues/3733/reactions"", ""total_count"": 0, ""+1"": 0, ""-1"": 0, ""laugh"": 0, ""hooray"": 0, ""confused"": 0, ""heart"": 0, ""rocket"": 0, ""eyes"": 0}",,,13221727,pull