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/125#issuecomment-43396609,https://api.github.com/repos/pydata/xarray/issues/125,43396609,MDEyOklzc3VlQ29tbWVudDQzMzk2NjA5,1217238,2014-05-17T03:39:56Z,2014-05-17T03:39:56Z,MEMBER,"I've been playing around with this but don't have a full fix yet. Here is my regression test for your bug:

```
    def test_index_and_concat_datetime64(self):
        # regression test for #125
        expected = Variable('t', pd.date_range('2011-09-01', periods=10))
        times = [expected[[i]] for i in range(10)]
        actual = Variable.concat(times, 't')
        self.assertArrayEqual(expected, actual)
```
","{""total_count"": 0, ""+1"": 0, ""-1"": 0, ""laugh"": 0, ""hooray"": 0, ""confused"": 0, ""heart"": 0, ""rocket"": 0, ""eyes"": 0}",,33307883
https://github.com/pydata/xarray/pull/125#issuecomment-43392029,https://api.github.com/repos/pydata/xarray/issues/125,43392029,MDEyOklzc3VlQ29tbWVudDQzMzkyMDI5,1217238,2014-05-17T00:24:16Z,2014-05-17T00:24:16Z,MEMBER,"Did you end up adding your example (concatenating the time objects) as a regression test? That seems like a good idea to ensure that this stays fixed!
","{""total_count"": 0, ""+1"": 0, ""-1"": 0, ""laugh"": 0, ""hooray"": 0, ""confused"": 0, ""heart"": 0, ""rocket"": 0, ""eyes"": 0}",,33307883
https://github.com/pydata/xarray/pull/125#issuecomment-43364230,https://api.github.com/repos/pydata/xarray/issues/125,43364230,MDEyOklzc3VlQ29tbWVudDQzMzY0MjMw,1217238,2014-05-16T18:30:49Z,2014-05-16T18:30:49Z,MEMBER,"Maybe best to open a new PR so it's clear what is new and what is just from the rebase?
","{""total_count"": 0, ""+1"": 0, ""-1"": 0, ""laugh"": 0, ""hooray"": 0, ""confused"": 0, ""heart"": 0, ""rocket"": 0, ""eyes"": 0}",,33307883
https://github.com/pydata/xarray/pull/125#issuecomment-43302438,https://api.github.com/repos/pydata/xarray/issues/125,43302438,MDEyOklzc3VlQ29tbWVudDQzMzAyNDM4,1217238,2014-05-16T06:52:23Z,2014-05-16T06:52:23Z,MEMBER,"Let me know how this is coming along!

I'd like to release v0.1.1 within the next few days, since #129 means that ReadTheDocs wasn't able to build versioned docs for v0.1, and we should have a static version of our docs built for the current release. At this point, adding and/or documenting new features means that the docs get out of sync with the latest release on pypi, which is obviously non-ideal. For example, the tutorial now mentions loading groups from NetCDF files even though that's not in v0.1.

I'm going to save #128 and any other highly visible changes for v0.2, but if think you're close to a fix for this issue I'd love to get it in 0.1.1. If not, it's no big deal to wait for 0.2, which I'm guessing will follow within a month or so.
","{""total_count"": 0, ""+1"": 0, ""-1"": 0, ""laugh"": 0, ""hooray"": 0, ""confused"": 0, ""heart"": 0, ""rocket"": 0, ""eyes"": 0}",,33307883
https://github.com/pydata/xarray/pull/125#issuecomment-42981862,https://api.github.com/repos/pydata/xarray/issues/125,42981862,MDEyOklzc3VlQ29tbWVudDQyOTgxODYy,1217238,2014-05-13T16:56:33Z,2014-05-13T16:56:33Z,MEMBER,"Indeed, it would be nice to make that consistent!

I was making some effort to not automatically convert python or netCDF4 datetime objects into numpy.datetime64, for the hypothetical situation where people care about dates before 1677 or aren't using standard calendars (but this will change with #126). But if that's too complicated, feel free to insist on the pandas approach of converting everything to nanosecond datetime64.
","{""total_count"": 0, ""+1"": 0, ""-1"": 0, ""laugh"": 0, ""hooray"": 0, ""confused"": 0, ""heart"": 0, ""rocket"": 0, ""eyes"": 0}",,33307883
https://github.com/pydata/xarray/pull/125#issuecomment-42951350,https://api.github.com/repos/pydata/xarray/issues/125,42951350,MDEyOklzc3VlQ29tbWVudDQyOTUxMzUw,514053,2014-05-13T13:02:22Z,2014-05-13T13:02:22Z,CONTRIBUTOR,"Yeah this gets tricky.  Fixed part of the problem by reverting to using np.asarray instead of as_array_or_item  in NumpyArrayWrapper.  But I'm not sure thats the full solution, like you mentioned the problem is much deeper, though I don't think pushing the datetime nastiness into higher level functions (such as concat) is a great option.

Also, I've been hoping to get the way dates are handled to be slightly more consistent, since as it currently stands its hard to know which data type dates are being stored as.

```
> d64 =  np.datetime64(d)
> print xray.Variable(['time'], [d]).dtype
dtype('O')
> print xray.Variable(['time'], [d64]).dtype
dtype('<M8[ns]')
> print d64.dtype
dtype('<M8[us]')
```

I'm going to attempt getting utils.as_safe_array to convert from datetime objects to datetime64 objects which should make things a little clearer, but still doesn't solve the whole problem.
","{""total_count"": 0, ""+1"": 0, ""-1"": 0, ""laugh"": 0, ""hooray"": 0, ""confused"": 0, ""heart"": 0, ""rocket"": 0, ""eyes"": 0}",,33307883
https://github.com/pydata/xarray/pull/125#issuecomment-42863294,https://api.github.com/repos/pydata/xarray/issues/125,42863294,MDEyOklzc3VlQ29tbWVudDQyODYzMjk0,1217238,2014-05-12T17:39:35Z,2014-05-12T17:39:35Z,MEMBER,"Wow, that is nasty! As you can see, we currently have a lot of awkward hacks to work around numpy's semi-broken datetime64, and it looks like this fix broke some of them -- hence the failing Travis builds.

Maybe we need some special logic in `Variable.concat` instead? My _guess_ is that the trouble here is related to all these datetime64 objects (plain `np.datetime64` objects, not arrays with `dtype='datetime64'`, because 0-dimensional datetime64 arrays are broken) being put into an array directly, which at some point implicitly converts them into integers.
","{""total_count"": 0, ""+1"": 0, ""-1"": 0, ""laugh"": 0, ""hooray"": 0, ""confused"": 0, ""heart"": 0, ""rocket"": 0, ""eyes"": 0}",,33307883