home / github / issue_comments

Menu
  • GraphQL API
  • Search all tables

issue_comments: 820832966

This data as json

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-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.

  1. 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, so I think we could be open to adding both to xarray.

  1. 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
Powered by Datasette · Queries took 0.584ms · About: xarray-datasette