issue_comments: 237560363

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/pull/940#issuecomment-237560363 https://api.github.com/repos/pydata/xarray/issues/940 237560363 MDEyOklzc3VlQ29tbWVudDIzNzU2MDM2Mw== 950575 2016-08-04T13:56:40Z 2016-08-04T13:56:40Z CONTRIBUTOR

This is ready for review.

Here is an example of this PR in action showing how plotting and working with periods gets easier with floats instead of timedeltas.

BTW, in light of https://github.com/pydata/xarray/issues/939#issue-169274464, I wonder if decode_timedeltas and decode_datetimes (or even the original decode_times) are needed at all. (Just defending myself as I don't really want a new keyword argument but a better default for time data in general :grimacing:)

Maybe I am being thick and I don't know enough use cases data but I cannot see why someone might want to convert time data (which most of the time represent periods) to timedeltas. That breaks from the original data units and forces the user to compute it back and convert the dtype too before for plotting, etc.

Regarding time coordinate itself I understand that xarray, due to the pandas nature of the index, needs to fail to convert time when the calendar is not supported by pandas. Maybe, instead of throwing an error and asking the users to use the option decode_(date)times=False in case of failure, xarray could issue an warning and return only the "numbers" as if decode_(date)times were set to False.

I understand, and agree most of the time, that raising erros is better than issuing warnings, and creating an ambiguity in the returns. So maybe this one is harder to change than the former.

 
{
    "total_count": 0,
    "+1": 0,
    "-1": 0,
    "laugh": 0,
    "hooray": 0,
    "confused": 0,
    "heart": 0,
    "rocket": 0,
    "eyes": 0
}
   169276671