Set longdouble=False in cftime.date2num within the date encoding context

[spencerkclark]

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, 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 (Unidata/cftime#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), 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

[dcherian]

Seems good to me.

thanks @spencerkclark

Shall we open an issue with your first comment to keep track of this?

[spencerkclark]

Thanks @dcherian — yes it probably would be good to create an issue to track further discussion about this. Encoding times with float128 values might be of interest to some. I’ll create one tomorrow.