issue_comments

Table actions

2 rows where author_association = "MEMBER" and issue = 1196270877 sorted by updated_at descending

✎ View and edit SQL

This data as json, CSV (advanced)

Suggested facets: created_at (date), updated_at (date)

user 1

issue 1

  • In a specific case, `decode_cf` adds encoding dtype that breaks `to_netcdf` · 2 ✖

author_association 1

  • MEMBER · 2 ✖
id html_url issue_url node_id user created_at updated_at ▲ author_association body reactions performed_via_github_app issue
1100895150 https://github.com/pydata/xarray/issues/6453#issuecomment-1100895150 https://api.github.com/repos/pydata/xarray/issues/6453 IC_kwDOAMm_X85BnlOu spencerkclark 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 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.

 
{
    "total_count": 0,
    "+1": 0,
    "-1": 0,
    "laugh": 0,
    "hooray": 0,
    "confused": 0,
    "heart": 0,
    "rocket": 0,
    "eyes": 0
}
   In a specific case, `decode_cf` adds encoding dtype that breaks `to_netcdf` 1196270877
1094145183 https://github.com/pydata/xarray/issues/6453#issuecomment-1094145183 https://api.github.com/repos/pydata/xarray/issues/6453 IC_kwDOAMm_X85BN1Sf spencerkclark 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
}
   In a specific case, `decode_cf` adds encoding dtype that breaks `to_netcdf` 1196270877

Advanced export

JSON shape: default, array, newline-delimited, object

CSV options: 

CREATE TABLE [issue_comments] (
   [html_url] TEXT,
   [issue_url] TEXT,
   [id] INTEGER PRIMARY KEY,
   [node_id] TEXT,
   [user] INTEGER REFERENCES [users]([id]),
   [created_at] TEXT,
   [updated_at] TEXT,
   [author_association] TEXT,
   [body] TEXT,
   [reactions] TEXT,
   [performed_via_github_app] TEXT,
   [issue] INTEGER REFERENCES [issues]([id])
);
CREATE INDEX [idx_issue_comments_issue]
    ON [issue_comments] ([issue]);
CREATE INDEX [idx_issue_comments_user]
    ON [issue_comments] ([user]);