issue_comments

Table actions

3 rows where issue = 146908323 sorted by updated_at descending

✎ View and edit SQL

This data as json, CSV (advanced)

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

user 2

author_association 2

issue 1

  • datetime units interpretation wrong in special cases · 3 ✖
id html_url issue_url node_id user created_at updated_at ▲ author_association body reactions performed_via_github_app issue
207817562 https://github.com/pydata/xarray/issues/821#issuecomment-207817562 https://api.github.com/repos/pydata/xarray/issues/821 MDEyOklzc3VlQ29tbWVudDIwNzgxNzU2Mg== forman 206773 2016-04-09T16:54:10Z 2016-04-09T16:55:10Z NONE

After some testing I found the problem. The single value of the time coordinate is wrong in the files. So it is a file content problem not a problem in the software. Therefore I'll close this issue.

However, Panoply displays the time information correctly and I found out why: Panoply correctly interprets the time_bnds variable to which the time coordinate variable points to via its attribute bounds. Since this is conforming to CF, I wonder whether xarray should support this bounds convention. From the CF conventions 1.6:

It is often the case that data values are not representative of single points in time and/or space, but rather of intervals or multidimensional cells. This convention defines a bounds attribute to specify the extent of intervals or cells. When data that is representative of cells can be described by simple statistical methods, those methods can be indicated using the cell_methods attribute. An important application of this attribute is to describe climatological and diurnal statistics.

Details are in Section 7.1 Cell Boundaries

 
{
    "total_count": 0,
    "+1": 0,
    "-1": 0,
    "laugh": 0,
    "hooray": 0,
    "confused": 0,
    "heart": 0,
    "rocket": 0,
    "eyes": 0
}
   datetime units interpretation wrong in special cases 146908323
207790447 https://github.com/pydata/xarray/issues/821#issuecomment-207790447 https://api.github.com/repos/pydata/xarray/issues/821 MDEyOklzc3VlQ29tbWVudDIwNzc5MDQ0Nw== forman 206773 2016-04-09T13:39:17Z 2016-04-09T13:39:17Z NONE

Thanks, I'll give it a try.

 
{
    "total_count": 0,
    "+1": 0,
    "-1": 0,
    "laugh": 0,
    "hooray": 0,
    "confused": 0,
    "heart": 0,
    "rocket": 0,
    "eyes": 0
}
   datetime units interpretation wrong in special cases 146908323
207554987 https://github.com/pydata/xarray/issues/821#issuecomment-207554987 https://api.github.com/repos/pydata/xarray/issues/821 MDEyOklzc3VlQ29tbWVudDIwNzU1NDk4Nw== shoyer 1217238 2016-04-08T18:52:26Z 2016-04-08T18:52:26Z MEMBER

This may be related to https://github.com/pydata/xarray/issues/545

Likely this is due to numeric overflow of some sort in our datetime decoding function. This is the internal function that handles decoding dates if you're interested in digging into this: https://github.com/pydata/xarray/blob/v0.7.2/xarray/conventions.py#L115

 
{
    "total_count": 0,
    "+1": 0,
    "-1": 0,
    "laugh": 0,
    "hooray": 0,
    "confused": 0,
    "heart": 0,
    "rocket": 0,
    "eyes": 0
}
   datetime units interpretation wrong in special cases 146908323

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