issue_comments

Table actions

3 rows where author_association = "MEMBER", issue = 235542564 and user = 10194086 sorted by updated_at descending

✎ View and edit SQL

This data as json, CSV (advanced)

These facets timed out: author_association, issue

user 1

  • mathause · 3 ✖
id html_url issue_url node_id user created_at updated_at ▲ author_association body reactions performed_via_github_app issue
494446221 https://github.com/pydata/xarray/pull/1451#issuecomment-494446221 https://api.github.com/repos/pydata/xarray/issues/1451 MDEyOklzc3VlQ29tbWVudDQ5NDQ0NjIyMQ== mathause 10194086 2019-05-21T15:42:37Z 2019-05-21T15:42:37Z MEMBER

Ok, I just had a look & things still look pretty much the same. Not sure if/ when I find time to do this,

 
{
    "total_count": 0,
    "+1": 0,
    "-1": 0,
    "laugh": 0,
    "hooray": 0,
    "confused": 0,
    "heart": 0,
    "rocket": 0,
    "eyes": 0
}
   inconsistent time.units fmt in encode_cf_datetime 235542564
493124795 https://github.com/pydata/xarray/pull/1451#issuecomment-493124795 https://api.github.com/repos/pydata/xarray/issues/1451 MDEyOklzc3VlQ29tbWVudDQ5MzEyNDc5NQ== mathause 10194086 2019-05-16T15:51:06Z 2019-05-16T15:51:06Z MEMBER

I have a feeling that there where quite some changes to this part of the code (but I'm not sure) - so I'd have to look into it first.

 
{
    "total_count": 0,
    "+1": 0,
    "-1": 0,
    "laugh": 0,
    "hooray": 0,
    "confused": 0,
    "heart": 0,
    "rocket": 0,
    "eyes": 0
}
   inconsistent time.units fmt in encode_cf_datetime 235542564
308734219 https://github.com/pydata/xarray/pull/1451#issuecomment-308734219 https://api.github.com/repos/pydata/xarray/issues/1451 MDEyOklzc3VlQ29tbWVudDMwODczNDIxOQ== mathause 10194086 2017-06-15T13:48:13Z 2017-06-15T13:48:13Z MEMBER

I tried to dig a bit into this...

The reason behind _cleanup_netcdf_time_units is to clean up things as u'Hour␣␣since 1680-01-01 00:00:00' (double space). However, it does not correct for the case (e.g. daYs remains daYs). Also, the clean up is not tested. This seems to be a reasonable thing to do, but, as mentioned the ref_date is changed, too. Thus we have to decide if

  • we want to keep the cleaning of the "Hour since" part, and if the case should be corrected as well (daYs). If yes potentially add tests.
  • the user-defined ref_date string (e.g. 2015-01-01) should be changed (I would say no). And if no, if it needs a sanity check or if pd.Timestamp(ref_date) does the sanity check for us.

In the CF conventions they refer to the udunits library. And, as mentioned, provide examples without "T". But this seems to be the standard in udunits, version 1. While in the udunits, version 2, the timestamp format includes "T".

TIMSTAMP: <year> (<month> <day>?)? "T" <hour> (<minute> <second>?)?

But udunits2 also mentions that it should be able to parse all formats of udunits1. So leaving out the "T" seems to be the safer option.

 
{
    "total_count": 0,
    "+1": 0,
    "-1": 0,
    "laugh": 0,
    "hooray": 0,
    "confused": 0,
    "heart": 0,
    "rocket": 0,
    "eyes": 0
}
   inconsistent time.units fmt in encode_cf_datetime 235542564

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