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/6453#issuecomment-1100895150,https://api.github.com/repos/pydata/xarray/issues/6453,1100895150,IC_kwDOAMm_X85BnlOu,6628425,2022-04-17T14:55:56Z,2022-04-17T14:55:56Z,MEMBER,"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 calling `decode_cf_variable` on a variable that already has a `datetime64[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.","{""total_count"": 0, ""+1"": 0, ""-1"": 0, ""laugh"": 0, ""hooray"": 0, ""confused"": 0, ""heart"": 0, ""rocket"": 0, ""eyes"": 0}",,1196270877 https://github.com/pydata/xarray/issues/6453#issuecomment-1094145183,https://api.github.com/repos/pydata/xarray/issues/6453,1094145183,IC_kwDOAMm_X85BN1Sf,6628425,2022-04-10T00:07:42Z,2022-04-10T00:07:42Z,MEMBER,"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.","{""total_count"": 0, ""+1"": 0, ""-1"": 0, ""laugh"": 0, ""hooray"": 0, ""confused"": 0, ""heart"": 0, ""rocket"": 0, ""eyes"": 0}",,1196270877