issue_comments

Table actions

3 rows where author_association = "MEMBER", issue = 33359402 and user = 1217238 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

  • shoyer · 3 ✖

issue 1

  • Return numpy.datetime64 arrays for non-standard calendars · 3 ✖

author_association 1

  • MEMBER · 3 ✖
id html_url issue_url node_id user created_at updated_at ▲ author_association body reactions performed_via_github_app issue
43282787 https://github.com/pydata/xarray/pull/126#issuecomment-43282787 https://api.github.com/repos/pydata/xarray/issues/126 MDEyOklzc3VlQ29tbWVudDQzMjgyNzg3 shoyer 1217238 2014-05-16T00:39:54Z 2014-05-16T00:39:54Z MEMBER

I just closed them. There is actually a cool feature of GitHub where if you write your commit message in the form "Fixes #118" the issue gets closed automatically upon merging: https://help.github.com/articles/closing-issues-via-commit-messages

 
{
    "total_count": 0,
    "+1": 0,
    "-1": 0,
    "laugh": 0,
    "hooray": 0,
    "confused": 0,
    "heart": 0,
    "rocket": 0,
    "eyes": 0
}
   Return numpy.datetime64 arrays for non-standard calendars 33359402
43281517 https://github.com/pydata/xarray/pull/126#issuecomment-43281517 https://api.github.com/repos/pydata/xarray/issues/126 MDEyOklzc3VlQ29tbWVudDQzMjgxNTE3 shoyer 1217238 2014-05-16T00:22:05Z 2014-05-16T00:22:05Z MEMBER

Thanks you, Joe!

 
{
    "total_count": 0,
    "+1": 0,
    "-1": 0,
    "laugh": 0,
    "hooray": 0,
    "confused": 0,
    "heart": 0,
    "rocket": 0,
    "eyes": 0
}
   Return numpy.datetime64 arrays for non-standard calendars 33359402
42985094 https://github.com/pydata/xarray/pull/126#issuecomment-42985094 https://api.github.com/repos/pydata/xarray/issues/126 MDEyOklzc3VlQ29tbWVudDQyOTg1MDk0 shoyer 1217238 2014-05-13T17:22:17Z 2014-05-13T17:22:17Z MEMBER

The issue with the 360_day calendar is sort of what I was afraid of with the non-standard calendars. I think issuing warnings is a reasonable solution, but perhaps it would be better to not even try to convert dates with calendars that can't be safely converted? That would be slightly more predictable (I would still probably issue a warning in those cases). Looking at the standard NetCDF calendars it appears that the only problematic ones would be "all_leap"/"366_day" and "uniform30day"/"360_day".

It would also be nice if you could also issue a warning when we fall back to netCDF4 datetime objects because there are dates outside the valid range. The DecodedCFDatetimeArray object pretends to have dtype=np.datetime64, and in this case the values turn out not to be.

In terms of tests: 1. Please also verify that converting a single element returns what you expect. This should be a np.datetime64 object, not a 0-dimensional datetime64 array, since numpy's support for these is semi-broken. 2. Please use a context manager to verify that the warning you expect is issued. This also keeps expected warnings from polluting our test output. See: https://docs.python.org/2/library/warnings.html#testing-warnings

 
{
    "total_count": 0,
    "+1": 0,
    "-1": 0,
    "laugh": 0,
    "hooray": 0,
    "confused": 0,
    "heart": 0,
    "rocket": 0,
    "eyes": 0
}
   Return numpy.datetime64 arrays for non-standard calendars 33359402

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