issue_comments: 276719845
This data as json
| html_url | issue_url | id | node_id | user | created_at | updated_at | author_association | body | reactions | performed_via_github_app | issue |
|---|---|---|---|---|---|---|---|---|---|---|---|
| https://github.com/pydata/xarray/issues/1084#issuecomment-276719845 | https://api.github.com/repos/pydata/xarray/issues/1084 | 276719845 | MDEyOklzc3VlQ29tbWVudDI3NjcxOTg0NQ== | 1217238 | 2017-02-01T17:17:46Z | 2017-02-01T17:19:48Z | MEMBER | @spencerkclark I still think subclassing pandas.Index is the best path forward. Subclassing DatetimeIndex is a non-starter because it presumes the use of datetime64 internally. Subclassing PeriodIndex is also potentially viable, but would require hooking pretty deeply into pandas's internal machinery with an API that isn't really designed to be extended externally. For example, frequency conversion is done in C. From a data model perspective, it might work to use custom frequencies for different calendars, but it's not the cleanest abstraction -- really the frequency and the calendar are two separate notions. From a practical perspective, it's also less promising because it would require writing much of the logic from netcdftime to reimplement arithmetic and so on. And there would still be issues with datetime strings and converting back and forth to datetimes. The downside of using pandas.Index is that resampling won't work out of the box. But we can work around that in xarray, and potentially even in pandas if we add an a simple dispatching mechanism into |
{
"total_count": 1,
"+1": 1,
"-1": 0,
"laugh": 0,
"hooray": 0,
"confused": 0,
"heart": 0,
"rocket": 0,
"eyes": 0
} |
187591179 |