issues

Table actions

2 rows where milestone = 836999, state = "closed" and type = "issue" sorted by updated_at descending

✎ View and edit SQL

This data as json, CSV (advanced)

Suggested facets: created_at (date), updated_at (date), closed_at (date)

type 1

  • issue · 2 ✖

state 1

  • closed · 2 ✖

repo 1

id node_id number title user state locked assignee milestone comments created_at updated_at ▲ closed_at author_association active_lock_reason draft pull_request body reactions performed_via_github_app state_reason repo type
33833155 MDU6SXNzdWUzMzgzMzE1NQ== 136 More consistent datetime conversion shoyer 1217238 closed 0   0.3.2 836999 0 2014-05-19T20:16:32Z 2014-12-19T20:54:51Z 2014-12-19T05:27:50Z MEMBER      

Todo: - [x] Decide on rules for datetime conversion - [x] Implement them - [ ] Document them

Currently: - All np.datetime64 arrays or objects are converted to ns precision - We leave other datetime or datetime-like objects intact in numpy arrays of dtype=object.

Arguably, we should convert everything to 'datetime64[ns]', if possible. This is the approach we now take for decoding NetCDF time variables (#126).

Reference discussion: #134. From @akleeman:

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.

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

 
{
    "url": "https://api.github.com/repos/pydata/xarray/issues/136/reactions",
    "total_count": 0,
    "+1": 0,
    "-1": 0,
    "laugh": 0,
    "hooray": 0,
    "confused": 0,
    "heart": 0,
    "rocket": 0,
    "eyes": 0
}
   completed xarray 13221727 issue
49478188 MDU6SXNzdWU0OTQ3ODE4OA== 279 BUG: reindex method creates new dims/coords ToddSmall 4194485 closed 0   0.3.2 836999 0 2014-11-20T01:29:21Z 2014-12-19T07:21:31Z 2014-12-19T07:21:31Z NONE      

If you reindex an xray dataset or dataarray with a coordinate with a different name, an extra dimension and coordinate is added to the xray object (with the name of the reindexing coordinate). Here's a simple example:

x1 = xray.DataArray(np.random.randn(5, 6, 7), dims=["lon", "lat", "time"]) time2 = xray.DataArray([1, 3], dims="time2") x2 = x1.reindex(time=time2)

x2 now has coordinates "time" and "time2".

I'm using xray version 0.3.1-4-gee1369f.

 
{
    "url": "https://api.github.com/repos/pydata/xarray/issues/279/reactions",
    "total_count": 0,
    "+1": 0,
    "-1": 0,
    "laugh": 0,
    "hooray": 0,
    "confused": 0,
    "heart": 0,
    "rocket": 0,
    "eyes": 0
}
   completed xarray 13221727 issue

Advanced export

JSON shape: default, array, newline-delimited, object

CSV options: 

CREATE TABLE [issues] (
   [id] INTEGER PRIMARY KEY,
   [node_id] TEXT,
   [number] INTEGER,
   [title] TEXT,
   [user] INTEGER REFERENCES [users]([id]),
   [state] TEXT,
   [locked] INTEGER,
   [assignee] INTEGER REFERENCES [users]([id]),
   [milestone] INTEGER REFERENCES [milestones]([id]),
   [comments] INTEGER,
   [created_at] TEXT,
   [updated_at] TEXT,
   [closed_at] TEXT,
   [author_association] TEXT,
   [active_lock_reason] TEXT,
   [draft] INTEGER,
   [pull_request] TEXT,
   [body] TEXT,
   [reactions] TEXT,
   [performed_via_github_app] TEXT,
   [state_reason] TEXT,
   [repo] INTEGER REFERENCES [repos]([id]),
   [type] TEXT
);
CREATE INDEX [idx_issues_repo]
    ON [issues] ([repo]);
CREATE INDEX [idx_issues_milestone]
    ON [issues] ([milestone]);
CREATE INDEX [idx_issues_assignee]
    ON [issues] ([assignee]);
CREATE INDEX [idx_issues_user]
    ON [issues] ([user]);