home / github

Menu
  • Search all tables
  • GraphQL API

issue_comments

Table actions
  • GraphQL API for issue_comments

6 rows where author_association = "MEMBER" and issue = 139956689 sorted by updated_at descending

✖
✖
✖

✎ View and edit SQL

This data as json, CSV (advanced)

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

user 4

  • shoyer 2
  • jhamman 2
  • rabernat 1
  • max-sixty 1

issue 1

  • Time limitation (between years 1678 and 2262) restrictive to climate community · 6 ✖

author_association 1

  • MEMBER · 6 ✖
id html_url issue_url node_id user created_at updated_at ▲ author_association body reactions performed_via_github_app issue
219928912 https://github.com/pydata/xarray/issues/789#issuecomment-219928912 https://api.github.com/repos/pydata/xarray/issues/789 MDEyOklzc3VlQ29tbWVudDIxOTkyODkxMg== jhamman 2443309 2016-05-18T05:29:20Z 2016-05-18T05:29:20Z MEMBER

@brews - I think this issue (https://github.com/pydata/pandas/issues/7307) covers the main gist of what we're talking about here.

{
    "total_count": 0,
    "+1": 0,
    "-1": 0,
    "laugh": 0,
    "hooray": 0,
    "confused": 0,
    "heart": 0,
    "rocket": 0,
    "eyes": 0
}
  Time limitation (between years 1678 and 2262) restrictive to climate community 139956689
195031692 https://github.com/pydata/xarray/issues/789#issuecomment-195031692 https://api.github.com/repos/pydata/xarray/issues/789 MDEyOklzc3VlQ29tbWVudDE5NTAzMTY5Mg== jhamman 2443309 2016-03-10T20:23:26Z 2016-03-10T20:23:26Z MEMBER

This might make slightly more sense in a related but distinct project to xarray.

@shoyer - are you thinking xarray would fall back to a CustomDatetimeIndex for non-standard calendars?

I actually don't think it would be all that hard to do this. @jswhit's netcdftime module is at least a good starting point. There's a lot to build on in netcdftime and pandas.tseries.index. I'd actually say this should be targeted at Pandas (probably as a side project) rather than xarray. Ultimately, it would be nice to be able to move timeseries back and forth without any hassle.

I'd be happy to help pull this together, although, I won't be able to make significant contributions until the summer. Is anyone chomping at the bit to work on something like this?

{
    "total_count": 0,
    "+1": 0,
    "-1": 0,
    "laugh": 0,
    "hooray": 0,
    "confused": 0,
    "heart": 0,
    "rocket": 0,
    "eyes": 0
}
  Time limitation (between years 1678 and 2262) restrictive to climate community 139956689
194988376 https://github.com/pydata/xarray/issues/789#issuecomment-194988376 https://api.github.com/repos/pydata/xarray/issues/789 MDEyOklzc3VlQ29tbWVudDE5NDk4ODM3Ng== shoyer 1217238 2016-03-10T18:22:38Z 2016-03-10T19:46:33Z MEMBER

Well, the good news is that non-standard calendars like 365 are actually a bit easier than the Gregorian calendar, at least if you were starting from scratch. As much as I love pushing fixes upstream, the most sane approach is to probably write a CustomDatetimeIndex class from scratch and start checking off boxes on datetime functionality: - [ ] support for datetime indexing functionality (the pandas get_indexer, get_loc and slice_indexer methods) - [ ] support for pulling out datetime components (e.g., year or hour) - [ ] support for resample (I'm not exactly sure what the right API is here)

This might make slightly more sense in a related but distinct project to xarray.

NumPy and pandas developers will listen sympathetically, but ultimately nobody is going to work on this unless there is funding or they need it for their own work -- that's just how open source works. Fixing the underlying technology so these problems can be solved the "right" way is on the roadmap, but only in a vague, we'll get to it eventually kind of way.

{
    "total_count": 0,
    "+1": 0,
    "-1": 0,
    "laugh": 0,
    "hooray": 0,
    "confused": 0,
    "heart": 0,
    "rocket": 0,
    "eyes": 0
}
  Time limitation (between years 1678 and 2262) restrictive to climate community 139956689
195010525 https://github.com/pydata/xarray/issues/789#issuecomment-195010525 https://api.github.com/repos/pydata/xarray/issues/789 MDEyOklzc3VlQ29tbWVudDE5NTAxMDUyNQ== max-sixty 5635139 2016-03-10T19:29:40Z 2016-03-10T19:29:40Z MEMBER

Periods can go back much further, depending on the precision you need:

python In [26]: pd.Period('1000', freq='D') Out[26]: Period('1000-01-01', 'D')

{
    "total_count": 0,
    "+1": 0,
    "-1": 0,
    "laugh": 0,
    "hooray": 0,
    "confused": 0,
    "heart": 0,
    "rocket": 0,
    "eyes": 0
}
  Time limitation (between years 1678 and 2262) restrictive to climate community 139956689
194976812 https://github.com/pydata/xarray/issues/789#issuecomment-194976812 https://api.github.com/repos/pydata/xarray/issues/789 MDEyOklzc3VlQ29tbWVudDE5NDk3NjgxMg== rabernat 1197350 2016-03-10T17:56:27Z 2016-03-10T17:56:27Z MEMBER

:+1: I hit this problem months back when analyzing CESM runs.

It seems silly that the adoption of xarray by the climate modeling community should rest on these highly technical issues. But that seems to be the reality. The challenge is to raise the profile of these issues within the numpy and pandas communities such that they become a high priority. Even better would be dedicated developer time (e.g. from someone at UNIDATA) to implement fixes.

{
    "total_count": 0,
    "+1": 0,
    "-1": 0,
    "laugh": 0,
    "hooray": 0,
    "confused": 0,
    "heart": 0,
    "rocket": 0,
    "eyes": 0
}
  Time limitation (between years 1678 and 2262) restrictive to climate community 139956689
194971898 https://github.com/pydata/xarray/issues/789#issuecomment-194971898 https://api.github.com/repos/pydata/xarray/issues/789 MDEyOklzc3VlQ29tbWVudDE5NDk3MTg5OA== shoyer 1217238 2016-03-10T17:41:27Z 2016-03-10T17:41:27Z MEMBER

There are two issues here: 1. Support for years outside 1678-2262 -- blocked by pandas standardizing on nanosecond precision. 2. Support for custom calendars -- blocked by limitations of numpy's datetime64.

Unfortunately, I don't see easy fixes to either of these, though if I had to guess, adding support for other datetime precisions (perhaps only sub-second resolution) to pandas would be easier than fixing up NumPy's datetime64 itself (which is already pretty hacky).

{
    "total_count": 0,
    "+1": 0,
    "-1": 0,
    "laugh": 0,
    "hooray": 0,
    "confused": 0,
    "heart": 0,
    "rocket": 0,
    "eyes": 0
}
  Time limitation (between years 1678 and 2262) restrictive to climate community 139956689

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 15.26ms · About: xarray-datasette
  • Sort ascending
  • Sort descending
  • Facet by this
  • Hide this column
  • Show all columns
  • Show not-blank rows