ds['time.time'] is broken

[shoyer]

As noted in #364:

In [32]: t = pd.date_range('2000-01-01', periods=10, freq='H')

In [33]: time = xray.DataArray(t, name='time', dims='time')

In [34]: time['time.time']
Out[34]:
<xray.DataArray 'time' (time: 10)>
array(['1999-12-31T16:00:00.000000000-0800',
       '1999-12-31T17:00:00.000000000-0800',
       '1999-12-31T18:00:00.000000000-0800',
       '1999-12-31T19:00:00.000000000-0800',
       '1999-12-31T20:00:00.000000000-0800',
       '1999-12-31T21:00:00.000000000-0800',
       '1999-12-31T22:00:00.000000000-0800',
       '1999-12-31T23:00:00.000000000-0800',
       '2000-01-01T00:00:00.000000000-0800',
       '2000-01-01T01:00:00.000000000-0800'], dtype='datetime64[ns]')
Coordinates:
  * time     (time) datetime64[ns] 2000-01-01 2000-01-01T01:00:00 ...

It should return an array of datetime.time objects.

[shoyer]

We could hack around this, but ultimately this is an implication of a design choice I made for the internals of xray.DataArray, which stores its data in an internal xray.Dataset object, using self.name as the key for the variable with the array's data. This means it is currently impossible to have a DataArray with the same name as on of its coordinates but different values.

The real solution here is to do some internal refactoring to make this possible. My current thinking is to add a constant THIS_ARRAY = object() in xray.core.dataarray, and then use THIS_ARRAY instead of self.name in all internal methods that mess with the private dataset that stores the data on DataArray objects.

[shoyer]

To clarify: the issue here is that time.time involves the name "time" twice. If the data array is not called "time", then this works properly.

[jhamman]

@shoyer, just out of curiosity, was this broken before the changes to the virtual variable syntax in #357?

[shoyer]

@jhamman it was not broken before -- ds['time.time'] returned a variable named 'time.time', which does not conflict with 'time'.