issue_comments

After a little more investigating I think I've narrowed this down to the following example. This particular example happens to be problematic even with the development version of xarray (i.e. it is an existing bug): ``` In [1]: import pandas as pd ...: import xarray as xr

In [2]: times = pd.date_range("2000", periods=2)

In [3]: variable = xr.Variable(["time"], times)

In [4]: variable.encoding Out[4]: {}

In [5]: xr.conventions.decode_cf_variable(variable).encoding Out[5]: {'dtype': dtype('<M8[ns]')} `` The issue is that callingdecode_cf_variableon a variable that already has adatetime64[ns]dtype adds an encoding attribute that leads to problems downstream ('<M8[ns]'` is not a valid dtype in a netCDF file).

In this case it seems like we'd prefer not to add or modify any encoding attributes at all -- we are perfectly capable of handling empty encoding dictionaries for datetime-like data when writing it out to disk.

@spencerkclark Interesting! Good I am glad it is fixed with the dev version. Great if this work up can be used for a test.

Mostly, I wanted to also get this documented since it took forever to track down the issue — maybe it will save someone else some time when they are googling.

Thanks for the report! This is indeed odd behavior. I was able to reproduce this issue with the latest release of xarray, 2022.3.0, but interestingly when I try running the example with the development version of xarray, everything works:

``` DATASET1: {'long_name': 'time since initialization', 'field': 'time, scalar, series'} {'source': 'https://opendap.co-ops.nos.noaa.gov/thredds/dodsC/NOAA/CBOFS/MODELS/2022/04/09/nos.cbofs.regulargrid.n001.20220409.t00z.nc', 'original_shape': (1,), 'dtype': dtype('float64'), 'units': 'seconds since 2016-01-01 00:00:00', 'calendar': 'gregorian'} datetime64[ns] {'source': 'https://opendap.co-ops.nos.noaa.gov/thredds/dodsC/NOAA/CBOFS/MODELS/2022/04/09/nos.cbofs.regulargrid.n001.20220409.t00z.nc', 'original_shape': (1,), 'dtype': dtype('float64'), 'units': 'seconds since 2016-01-01 00:00:00', 'calendar': 'gregorian'}

DATASET2: {'long_name': 'time since initialization', 'units': 'seconds since 2016-01-01 00:00:00', 'calendar': 'gregorian', 'field': 'time, scalar, series'} {'source': 'https://opendap.co-ops.nos.noaa.gov/thredds/dodsC/NOAA/CBOFS/MODELS/2022/04/09/nos.cbofs.regulargrid.n001.20220409.t00z.nc', 'original_shape': (1,), 'dtype': dtype('float64')} float64 {'source': 'https://opendap.co-ops.nos.noaa.gov/thredds/dodsC/NOAA/CBOFS/MODELS/2022/04/09/nos.cbofs.regulargrid.n001.20220409.t00z.nc', 'original_shape': (1,), 'dtype': dtype('float64'), 'units': 'seconds since 2016-01-01 00:00:00', 'calendar': 'gregorian'}

DATASET3: {'long_name': 'time since initialization', 'field': 'time, scalar, series'} {'source': 'https://opendap.co-ops.nos.noaa.gov/thredds/dodsC/NOAA/CBOFS/MODELS/2022/04/09/nos.cbofs.regulargrid.n001.20220409.t00z.nc', 'original_shape': (1,), 'dtype': dtype('float64'), 'units': 'seconds since 2016-01-01 00:00:00', 'calendar': 'gregorian'} datetime64[ns] {'source': 'https://opendap.co-ops.nos.noaa.gov/thredds/dodsC/NOAA/CBOFS/MODELS/2022/04/09/nos.cbofs.regulargrid.n001.20220409.t00z.nc', 'original_shape': (1,), 'dtype': dtype('float64'), 'units': 'seconds since 2016-01-01 00:00:00', 'calendar': 'gregorian'} ```

It's good that this appears to be fixed, but it perhaps suggests we have some missing test coverage. I might see if I can develop a simple test we can add to our test suite.