html_url,issue_url,id,node_id,user,created_at,updated_at,author_association,body,reactions,performed_via_github_app,issue
https://github.com/pydata/xarray/issues/5155#issuecomment-953231867,https://api.github.com/repos/pydata/xarray/issues/5155,953231867,IC_kwDOAMm_X8440Sn7,6628425,2021-10-27T19:12:31Z,2021-10-27T19:12:31Z,MEMBER,"> Given the increasing scope of cftime-related utilities, I wonder if it would make sense to try to eventually move the cftime-related utilities outside of Xarray into a separate package? After the current ongoing ""explicit indexes"" refactor, I believe we will have public APIs for all of the essential functionality.
Yeah, I think that could be something good to strive for, and it's exciting that the explicit indexes refactor could facilitate that. To be clear, are you ok with merging #5233 and waiting until after the refactor is complete to discuss future plans there?","{""total_count"": 0, ""+1"": 0, ""-1"": 0, ""laugh"": 0, ""hooray"": 0, ""confused"": 0, ""heart"": 0, ""rocket"": 0, ""eyes"": 0}",,857947050
https://github.com/pydata/xarray/issues/5155#issuecomment-953076586,https://api.github.com/repos/pydata/xarray/issues/5155,953076586,IC_kwDOAMm_X844zstq,20629530,2021-10-27T16:06:01Z,2021-10-27T16:06:15Z,CONTRIBUTOR,"I agree that it kinda crowds the xarray API. My first idea was to implement these calendar utilities in `cf-xarray`, but I was redirected here. Seems to me that if that move is made, it's the most logical place for all CF[time] related things.","{""total_count"": 0, ""+1"": 0, ""-1"": 0, ""laugh"": 0, ""hooray"": 0, ""confused"": 0, ""heart"": 0, ""rocket"": 0, ""eyes"": 0}",,857947050
https://github.com/pydata/xarray/issues/5155#issuecomment-953065394,https://api.github.com/repos/pydata/xarray/issues/5155,953065394,IC_kwDOAMm_X844zp-y,1217238,2021-10-27T15:53:19Z,2021-10-27T15:53:19Z,MEMBER,"Given the increasing scope of cftime-related utilities, I wonder if it would make sense to try to eventually move the cftime-related utilities outside of Xarray into a separate package? After the current ongoing ""explicit indexes"" refactor, I believe we will have public APIs for all of the essential functionality.","{""total_count"": 0, ""+1"": 0, ""-1"": 0, ""laugh"": 0, ""hooray"": 0, ""confused"": 0, ""heart"": 0, ""rocket"": 0, ""eyes"": 0}",,857947050
https://github.com/pydata/xarray/issues/5155#issuecomment-825305166,https://api.github.com/repos/pydata/xarray/issues/5155,825305166,MDEyOklzc3VlQ29tbWVudDgyNTMwNTE2Ng==,6628425,2021-04-23T00:45:56Z,2021-04-23T00:45:56Z,MEMBER,"Great, thanks!
> Thus, I suggest we return ""standard"" as the calendar of numpy-backed datetime indexes.
I might actually lean toward your original thought, i.e. having `dt.calendar` return `""proleptic_gregorian""` for NumPy dates. As you noted, this is technically the calendar that `numpy.datetime64` values use with coarser precision. It is also what xarray currently chooses for the `calendar` encoding attribute for NumPy dates by default (i.e. if no `""calendar""` attribute exists in the variable's encoding).
(There is of course the complication that the NumPy dates could have been decoded from a file with a calendar attribute of `""standard""` or `""gregorian""`, in which case, if we are being as true to the underlying data as possible, returning `""proleptic_gregorian""` as the calendar type would then technically be incorrect. I'm not sure if there is really anything we could do about that though, since the encoding attributes can be lost through things like timedelta arithmetic. Arguably too, if someone wanted to quibble about that, I suppose their first issue should be with decoding those values to NumPy dates to begin with.) ","{""total_count"": 1, ""+1"": 1, ""-1"": 0, ""laugh"": 0, ""hooray"": 0, ""confused"": 0, ""heart"": 0, ""rocket"": 0, ""eyes"": 0}",,857947050
https://github.com/pydata/xarray/issues/5155#issuecomment-824379535,https://api.github.com/repos/pydata/xarray/issues/5155,824379535,MDEyOklzc3VlQ29tbWVudDgyNDM3OTUzNQ==,20629530,2021-04-21T21:46:42Z,2021-04-21T21:46:42Z,CONTRIBUTOR,"Edited the comment above as I realized that numpy /pandas / xarray use nanoseconds by default, so the earliest date possible is 1677-09-21 00:12:43.145225.
Thus, I suggest we return ""standard"" as the calendar of numpy-backed datetime indexes.","{""total_count"": 0, ""+1"": 0, ""-1"": 0, ""laugh"": 0, ""hooray"": 0, ""confused"": 0, ""heart"": 0, ""rocket"": 0, ""eyes"": 0}",,857947050
https://github.com/pydata/xarray/issues/5155#issuecomment-824373780,https://api.github.com/repos/pydata/xarray/issues/5155,824373780,MDEyOklzc3VlQ29tbWVudDgyNDM3Mzc4MA==,20629530,2021-04-21T21:37:59Z,2021-04-21T21:44:58Z,CONTRIBUTOR,"Cool! I started a branch, will push a PR soon.
I understand the ""default"" issue and using `use_cftime=None` makes sense to me!
~For `dt.calendar` and `date_range`, there remains the question on how we name numpy's calendar:
Python uses what CF conventions call `proleptic_gregorian`, but the default and most common calendar we see and use is CF's ""standard"". May be users would expect ""standard""?
A solution would be to check if the earliest value in the array is before 1582-10-15. If yes, return ""proleptic_gregorian"", if not, return ""standard"".~","{""total_count"": 0, ""+1"": 0, ""-1"": 0, ""laugh"": 0, ""hooray"": 0, ""confused"": 0, ""heart"": 0, ""rocket"": 0, ""eyes"": 0}",,857947050
https://github.com/pydata/xarray/issues/5155#issuecomment-820832966,https://api.github.com/repos/pydata/xarray/issues/5155,820832966,MDEyOklzc3VlQ29tbWVudDgyMDgzMjk2Ng==,6628425,2021-04-16T00:54:09Z,2021-04-16T00:54:28Z,MEMBER,"Thanks for opening up this discussion @aulemahal! It's great to see the boundaries being pushed on what can be done with cftime dates in xarray.
> 1. `ds.time.dt.calendar` would be magic
I think something like this would be cool too (see the end of https://github.com/pydata/xarray/pull/4092#discussion_r439101051). Attributes on the `dt` accessor normally return DataArrays with the same shape as the original, as opposed to scalar values, but it might be reasonable to make an exception in this case. Xarray, and CF conventions for that matter, are written in a way that assume that all dates in an array have the same calendar type, and therefore returning an array filled with the same calendar name feels far inferior to returning a scalar.
> 2. `xr.convert_calendar(ds, ""new_cal"")` could be nice?
Both `convert_calendar` and `interp_calendar` seem like very nice utilities. I have been fortunate enough not to have been in a situation to need something like those, but both of those methods seem like sensible and general approaches to the problem of converting a dataset from one calendar to another. I have seen this as an issue for others, e.g. [this SO question](https://stackoverflow.com/questions/66188904/ways-to-resample-non-standard-cftimeindex-calendars-360-day-no-leap-year-with/66195199?noredirect=1#comment117035233_66195199), so I think we could be open to adding both to xarray.
> 3. `xr.date_range(start, stop, calendar=cal)`, same as pandas' (see context below).
We actually considered something like this in the initial stages of writing `cftime_range`, but decided against it, https://github.com/pydata/xarray/pull/2301#issuecomment-407087972, https://github.com/pydata/xarray/pull/2301#discussion_r217577759. Maybe it is worth re-opening discussion about a possible more generic `xarray.date_range` function, though.
Using the calendar argument, as opposed to the range of the dates, to decide what type to return is a slightly different twist than what was discussed previously. I don't know how I feel about that. On one hand I can see why it would be convenient, but on the other hand `""default""` is not a valid CF calendar name so it feels a little strange to allow that as a special option to signal you want NumPy dates as a result. I wonder if instead we handled this in a way similar to decoding times, where we have a `use_cftime` argument? Basically you would have `xarray.date_range(..., use_cftime=use_cftime)`, where:
- If `use_cftime` were set to `False` it would only return NumPy dates and error if this was not possible
- If `use_cftime` were set to `None` (default) it would return NumPy dates if the calendar and time range allowed; otherwise it would return cftime dates
- And if `use_cftime` were set to `True` it would only return cftime dates.
Would that work for your use-case?","{""total_count"": 0, ""+1"": 0, ""-1"": 0, ""laugh"": 0, ""hooray"": 0, ""confused"": 0, ""heart"": 0, ""rocket"": 0, ""eyes"": 0}",,857947050
https://github.com/pydata/xarray/issues/5155#issuecomment-819570900,https://api.github.com/repos/pydata/xarray/issues/5155,819570900,MDEyOklzc3VlQ29tbWVudDgxOTU3MDkwMA==,20629530,2021-04-14T14:40:14Z,2021-04-14T14:40:14Z,CONTRIBUTOR,"@aaronspring Oh, I didn't think of that trick for 1, thanks! But again, this fails with numpy-backed time coordinates. With the definition of a ""default"" calendar, there could be a more general way.","{""total_count"": 0, ""+1"": 0, ""-1"": 0, ""laugh"": 0, ""hooray"": 0, ""confused"": 0, ""heart"": 0, ""rocket"": 0, ""eyes"": 0}",,857947050
https://github.com/pydata/xarray/issues/5155#issuecomment-819566971,https://api.github.com/repos/pydata/xarray/issues/5155,819566971,MDEyOklzc3VlQ29tbWVudDgxOTU2Njk3MQ==,12237157,2021-04-14T14:34:55Z,2021-04-14T14:34:55Z,CONTRIBUTOR,"1. exists as `ds.time.to_index().calendar`
2. would like to use","{""total_count"": 0, ""+1"": 0, ""-1"": 0, ""laugh"": 0, ""hooray"": 0, ""confused"": 0, ""heart"": 0, ""rocket"": 0, ""eyes"": 0}",,857947050