pull_requests: 1088466399
This data as json
id | node_id | number | state | locked | title | user | body | created_at | updated_at | closed_at | merged_at | merge_commit_sha | assignee | milestone | draft | head | base | author_association | auto_merge | repo | url | merged_by |
---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
1088466399 | PR_kwDOAMm_X85A4K3f | 7171 | closed | 0 | Set `longdouble=False` in `cftime.date2num` within the date encoding context | 6628425 | Currently, the default behavior of `cftime.date2num` is to return integer values when possible (i.e. when the encoding units allow), and fall back to returning float64 values when that is not possible. Recently, [cftime added the option to use float128 as the fallback dtype](https://github.com/Unidata/cftime/pull/284#issuecomment-1176098280), which enables greater potential roundtrip precision. This is through the `longdouble` flag to `cftime.date2num`, which currently defaults to `False`. It was intentionally set to `False` by default, because netCDF does not support storing float128 values in files, and so, without any changes, would otherwise break xarray's encoding procedure. The desire in cftime, however, is to eventually set this flag to `True` by default (https://github.com/Unidata/cftime/issues/297). This PR makes the necessary changes in xarray to adapt to this eventual new default. Essentially if the `longdouble` argument is allowed in the user's version of `cftime.date2num`, we explicitly set it to `False` to preserve the current float64 fallback behavior within the context of encoding times. There are a few more places where `date2num` is used (some additional places in the tests, and [in `calendar_ops.py`](https://github.com/pydata/xarray/blob/93f1ba226086d5a916f54653e870a2943fe09ab7/xarray/coding/calendar_ops.py#L277)), but in those places using float128 values would not present a problem. At some point we might consider relaxing this behavior in xarray, since it is possible to store float128 values in zarr stores for example, but for the time being the simplest approach seems to be to stick with float64 for all backends (it would be complicated to have backend-specific defaults). cc: @jswhit | 2022-10-16T18:20:58Z | 2022-10-18T16:38:24Z | 2022-10-18T16:37:57Z | 2022-10-18T16:37:57Z | 9df2dfca57e1c672f6faf0f7945d2f38921a4bb2 | 0 | 05853187cc1bb1d25cecad6c7de9c633a3ac4ec8 | 93f1ba226086d5a916f54653e870a2943fe09ab7 | MEMBER | 13221727 | https://github.com/pydata/xarray/pull/7171 |
Links from other tables
- 2 rows from pull_requests_id in labels_pull_requests