I'm not sure if this qualifies as a bug but this behavior was surprising to me. If I initialize two DataArrays with the same array, the two DataArrays and the original initialization array are all linked as if they are views of each other.

A simple example:

``` Python

initialize with same array:

a = np.zeros((4,4)) da1 = xray.DataArray(a, dims=['x', 'y']) da2 = xray.DataArray(a, dims=['i', 'j']) ```

If I do da1.loc[:, 2] = 12, the same change occurs in da2 and a. Likewise, doing da2[dict(i=1)] = 29 also modifies da1 and a.

The problem is fixed if I explicitly pass copies of the a but I think this should be the default behavior. If this behavior is intended then I think it should be clearly noted in the documentation.

```

xray.Dataset({'x': 1}).isnull().sum() <xray.Dataset> Dimensions: () Coordinates: empty Data variables: empty ```

This is a bug.

Recently, we introduced a distinction between "coordinates" and "variables" (see #197).

CF conventions make an analogous distinction between "coordinate variables" and "data variables": http://cfconventions.org/Data/cf-conventions/cf-conventions-1.6/build/cf-conventions.html

Would it be less confusing to use the CF terminology? I am leaning toward making this shift, because netCDF already has defined the term "variable", and xray's code still uses that internally. From a practical perspective, this would mean renaming Dataset.vars to Dataset.data_vars.

CC @akleeman @toddsmall

I have trouble reading NetCDF files obtained from MERRA. It turns out that their time unit is of the form "hours since 1982-1-10 0". Because there is only a single "0" for the hour, rather than "00", this is not an ISO compliant datetime string and pandas.Timestamp raises an error (see pydata/pandas#9434).

This makes it impossible to open such files unless passing decode_times=False to open_dataset().

I wonder if this is a rare edge case or if xray could attempt to intelligently handle it somewhere (maybe in conventions._unpack_netcdf_time_units). For now, I just used NCO to append an extra 0 to the time unit (luckily all files are the same, so I can just do this across the board): ncatted -O -a units,time,a,c,"0" file.nc

If we want to mimic pandas, we should support automatic alignment of coordinate labels in: - [x] Mathematical operations (non-inplace, ~~in-place~~, see also #184) - [x] All operations that add new dataset variables (merge, update, __setitem__). - [x] All operations that create a new dataset ( __init__, ~~concat~~)

For the later two cases, it is not clear that using an inner join on coordinate labels is the right choice, because that could lead to some surprising destructive operations. This should be considered carefully.

Instead, we should verify that that coordinates refer to valid variables and fail gracefully.

As reported by @mgarvert.

This is responsible for #205.