home / github

Menu
  • Search all tables
  • GraphQL API

issue_comments

Table actions
  • GraphQL API for issue_comments

5 rows where author_association = "MEMBER" and issue = 33359402 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

  • shoyer 3
  • jhamman 2

issue 1

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

author_association 1

  • MEMBER · 5 ✖
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
43282465 https://github.com/pydata/xarray/pull/126#issuecomment-43282465 https://api.github.com/repos/pydata/xarray/issues/126 MDEyOklzc3VlQ29tbWVudDQzMjgyNDY1 jhamman 2443309 2014-05-16T00:35:24Z 2014-05-16T00:35:24Z MEMBER

Sure thing. Do you want to close the associated issues (#118 and #121) or should I?

{
    "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
43251544 https://github.com/pydata/xarray/pull/126#issuecomment-43251544 https://api.github.com/repos/pydata/xarray/issues/126 MDEyOklzc3VlQ29tbWVudDQzMjUxNTQ0 jhamman 2443309 2014-05-15T19:04:15Z 2014-05-15T19:04:33Z MEMBER

I think this is all ready to go.

In the future and maybe as a separate project, I'd like to see more complete non-Gregorian calendar support in Python. I know the climate modeling community would utilize the feature. For now however, I think this is a good step for xray.

{
    "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]);
Powered by Datasette · Queries took 799.87ms · About: xarray-datasette