issue_comments: 1281138042

This data as json

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/pull/6812#issuecomment-1281138042 https://api.github.com/repos/pydata/xarray/issues/6812 1281138042 IC_kwDOAMm_X85MXJ16 2448579 2022-10-17T16:27:22Z 2022-10-17T16:27:22Z MEMBER

A big decision is if the decode option strictly follows CF guidelines.

I think our general position is to be flexible on what we can read because there are many slightly non-compliant files out there.

Xarray has written 10s (100s?) of tests that touch this decoding function that make assumptions that I believe are incorrect after a careful reading of the CF spec.

Some of these might just be for convenience and some might be checking that we are flexible in what we can read.

This following test should be preserved so we can read those files (#4631): @pytest.mark.parametrize("scale_factor", (10, [10])) @pytest.mark.parametrize("add_offset", (0.1, [0.1]))

Enforcing this would probably break xarray backward compatibility for writing files.

Do we not enforce that scale_factor and add_offset are of the same dtype on write? If so, we should consider that a bug and fix it.

I am concerned that this is a significant change and I'm not sure what the process is for making this change.

I think the way to move forward would be to figure out the smallest change that would fix (or even improve) #2304 and move on. We have a 30-minute bi-weekly meeting (#4001) that you're welcomed to attend and raise specific questions. The next one is Oct 26 at 9.30am Mountain Time

 
{
    "total_count": 0,
    "+1": 0,
    "-1": 0,
    "laugh": 0,
    "hooray": 0,
    "confused": 0,
    "heart": 0,
    "rocket": 0,
    "eyes": 0
}
   1309966595