issue_comments

Table actions

3 rows where issue = 33772168 and user = 514053 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

  • akleeman · 3 ✖

issue 1

  • Fix concatenating Variables with dtype=datetime64 · 3 ✖

author_association 1

id html_url issue_url node_id user created_at updated_at ▲ author_association body reactions performed_via_github_app issue
43545468 https://github.com/pydata/xarray/pull/134#issuecomment-43545468 https://api.github.com/repos/pydata/xarray/issues/134 MDEyOklzc3VlQ29tbWVudDQzNTQ1NDY4 akleeman 514053 2014-05-19T19:27:26Z 2014-05-19T19:27:26Z CONTRIBUTOR

Also worth considering: how should datetime64[us] datetimes be handled? Currently they get cast to [ns] which, since datetimes do not, could get confusing.

 
{
    "total_count": 0,
    "+1": 0,
    "-1": 0,
    "laugh": 0,
    "hooray": 0,
    "confused": 0,
    "heart": 0,
    "rocket": 0,
    "eyes": 0
}
   Fix concatenating Variables with dtype=datetime64 33772168
43535578 https://github.com/pydata/xarray/pull/134#issuecomment-43535578 https://api.github.com/repos/pydata/xarray/issues/134 MDEyOklzc3VlQ29tbWVudDQzNTM1NTc4 akleeman 514053 2014-05-19T17:55:00Z 2014-05-19T17:55:00Z CONTRIBUTOR

Yeah all fixed.

In #125 I went the route of forcing datetimes to be datetime64[ns]. This is probably part of a broader conversation, but doing so might save some future headaches. Of course ... it would also restrict us to nanosecond precision. Basically I feel like we should either force datetimes to be datetime64[ns] or make sure that operations on datetime objects preserve their type.

Probably worth getting this in and picking that conversation back up if needed. In which case could you add tests which make sure variables with datetime objects are still datetime objects after concatenation? If those start getting cast to datetime[ns] it'll start get confusing for users.

 
{
    "total_count": 0,
    "+1": 0,
    "-1": 0,
    "laugh": 0,
    "hooray": 0,
    "confused": 0,
    "heart": 0,
    "rocket": 0,
    "eyes": 0
}
   Fix concatenating Variables with dtype=datetime64 33772168
43473367 https://github.com/pydata/xarray/pull/134#issuecomment-43473367 https://api.github.com/repos/pydata/xarray/issues/134 MDEyOklzc3VlQ29tbWVudDQzNDczMzY3 akleeman 514053 2014-05-19T07:35:53Z 2014-05-19T07:35:53Z CONTRIBUTOR

The reorganization does make things cleaner, but the behavior changed relative to #125. In particular, while this patch fixes concatenation with datetime64 times it doesn't work with datetimes:

In [2]: dates = [datetime.datetime(2011, 1, i + 1) for i in range(10)] In [3]: ds = xray.Dataset({'time': ('time', dates)}) In [4]: xray.Dataset.concat([ds.indexed(time=slice(0, 4)), ds.indexed(time=slice(4, 8))], 'time')['time'].values Out[4]: array([1293840000000000000L, 1293926400000000000L, 1294012800000000000L, 1294099200000000000L, 1294185600000000000L, 1294272000000000000L, 1294358400000000000L, 1294444800000000000L], dtype=object)

and not sure if this was broken before or not ...

In [5]: xray.Dataset.concat([x for _, x in ds.groupby('time')], 'time')['time'].values ValueError: cannot slice a 0-d array

 
{
    "total_count": 0,
    "+1": 0,
    "-1": 0,
    "laugh": 0,
    "hooray": 0,
    "confused": 0,
    "heart": 0,
    "rocket": 0,
    "eyes": 0
}
   Fix concatenating Variables with dtype=datetime64 33772168

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]);