issue_comments

Table actions

2 rows where author_association = "NONE", issue = 264321376 and user = 1872600 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

  • rsignell-usgs · 2 ✖

issue 1

  • Undesired decoding to timedelta64 (was: units of "seconds" translated to time coordinate) · 2 ✖

author_association 1

  • NONE · 2 ✖
id html_url issue_url node_id user created_at updated_at ▲ author_association body reactions performed_via_github_app issue
339093278 https://github.com/pydata/xarray/issues/1621#issuecomment-339093278 https://api.github.com/repos/pydata/xarray/issues/1621 MDEyOklzc3VlQ29tbWVudDMzOTA5MzI3OA== rsignell-usgs 1872600 2017-10-24T18:50:21Z 2017-10-24T18:50:21Z NONE

I vote for 1 also. How many makes a quorum? :smile_cat: 

{
    "total_count": 0,
    "+1": 0,
    "-1": 0,
    "laugh": 0,
    "hooray": 0,
    "confused": 0,
    "heart": 0,
    "rocket": 0,
    "eyes": 0
}
   Undesired decoding to timedelta64 (was: units of "seconds" translated to time coordinate) 264321376
338172936 https://github.com/pydata/xarray/issues/1621#issuecomment-338172936 https://api.github.com/repos/pydata/xarray/issues/1621 MDEyOklzc3VlQ29tbWVudDMzODE3MjkzNg== rsignell-usgs 1872600 2017-10-20T10:46:53Z 2017-10-20T10:50:18Z NONE

On https://stackoverflow.com/a/46675990/2005869, @shoyer explains:

My understanding of CF standard names is that forecast_period should be equal to the difference between time and forecast_reference_time, i.e., forecast_period = time - forecast_reference_time. If you specified your time_offset variable with units in the form "hours", then it would be decoded to timedelta64, along with datetime64 for time and time_run, so xarray's arithmetic would actually satisfy this identity. You might find this useful if you only wanted to include two of these variables and wanted to calculate the third on the fly. On the other hand, you probably don't want to convert the Tper variable to timedelta64. Technically, it is also a time period, but it's not a variable that makes sense to compare to time.

I understand the potential issue here, but I think Xarray should follow CF conventions for time, and only treat variables as time coordinates if they have valid CF time units (<time unit> since <date>).

We know of thousands of datasets (every dataset with waves!) where the current Xarray behavior is a problem. 

{
    "total_count": 1,
    "+1": 1,
    "-1": 0,
    "laugh": 0,
    "hooray": 0,
    "confused": 0,
    "heart": 0,
    "rocket": 0,
    "eyes": 0
}
   Undesired decoding to timedelta64 (was: units of "seconds" translated to time coordinate) 264321376

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