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/1621#issuecomment-1114173984,https://api.github.com/repos/pydata/xarray/issues/1621,1114173984,IC_kwDOAMm_X85CaPIg,1217238,2022-05-01T08:49:40Z,2022-05-01T08:49:40Z,MEMBER,Still relevant!,"{""total_count"": 0, ""+1"": 0, ""-1"": 0, ""laugh"": 0, ""hooray"": 0, ""confused"": 0, ""heart"": 0, ""rocket"": 0, ""eyes"": 0}",,264321376
https://github.com/pydata/xarray/issues/1621#issuecomment-1114119503,https://api.github.com/repos/pydata/xarray/issues/1621,1114119503,IC_kwDOAMm_X85CaB1P,26384082,2022-05-01T03:37:48Z,2022-05-01T03:37:48Z,NONE,"In order to maintain a list of currently relevant issues, we mark issues as stale after a period of inactivity

If this issue remains relevant, please comment here or remove the `stale` label; otherwise it will be marked as closed automatically
","{""total_count"": 0, ""+1"": 0, ""-1"": 0, ""laugh"": 0, ""hooray"": 0, ""confused"": 0, ""heart"": 0, ""rocket"": 0, ""eyes"": 0}",,264321376
https://github.com/pydata/xarray/issues/1621#issuecomment-614990349,https://api.github.com/repos/pydata/xarray/issues/1621,614990349,MDEyOklzc3VlQ29tbWVudDYxNDk5MDM0OQ==,1197350,2020-04-17T01:46:04Z,2020-04-17T01:46:04Z,MEMBER,"> Now is a good time to make changes, since we are on the verge of making a major release (v0.10).

That ship has clearly sailed quite a while ago! 🤣 But I think I speak for many when I say THANK YOU @alexamici for taking this up again. Many people will still be very happy if this gets implemented.","{""total_count"": 1, ""+1"": 1, ""-1"": 0, ""laugh"": 0, ""hooray"": 0, ""confused"": 0, ""heart"": 0, ""rocket"": 0, ""eyes"": 0}",,264321376
https://github.com/pydata/xarray/issues/1621#issuecomment-614928175,https://api.github.com/repos/pydata/xarray/issues/1621,614928175,MDEyOklzc3VlQ29tbWVudDYxNDkyODE3NQ==,226037,2020-04-16T22:24:51Z,2020-04-16T22:24:51Z,MEMBER,"Ok, either @aurghs or I will take a shot at implementing `decode_timedelta=False` in the near future.","{""total_count"": 7, ""+1"": 7, ""-1"": 0, ""laugh"": 0, ""hooray"": 0, ""confused"": 0, ""heart"": 0, ""rocket"": 0, ""eyes"": 0}",,264321376
https://github.com/pydata/xarray/issues/1621#issuecomment-614893356,https://api.github.com/repos/pydata/xarray/issues/1621,614893356,MDEyOklzc3VlQ29tbWVudDYxNDg5MzM1Ng==,1217238,2020-04-16T21:01:01Z,2020-04-16T21:01:01Z,MEMBER,"I still think the ideal path forward is https://github.com/pydata/xarray/issues/1621#issuecomment-339116478, but clearly nobody was excited about taking on this effort :).

I do still think we _probably_ should retain a way to serialize/unserialize `timedelta64` data before we switch the default behavior, rather than breaking existing users without any recourse.

That said, we certainly could add an optional flag for disabling decoding to timedelta64 (e.g., `decode_timedelta=False` in `open_dataset`/`decode_cf`) now, without changing anything else in xarray. The default flag switch could be saved until later, when the new `timedelta64` serialization (steps 1 and 2 from above) works.","{""total_count"": 1, ""+1"": 1, ""-1"": 0, ""laugh"": 0, ""hooray"": 0, ""confused"": 0, ""heart"": 0, ""rocket"": 0, ""eyes"": 0}",,264321376
https://github.com/pydata/xarray/issues/1621#issuecomment-614879867,https://api.github.com/repos/pydata/xarray/issues/1621,614879867,MDEyOklzc3VlQ29tbWVudDYxNDg3OTg2Nw==,226037,2020-04-16T20:33:06Z,2020-04-16T20:33:06Z,MEMBER,"@shoyer I'm hitting this on *xarray* 0.15.1 so I guess the effort had stalled.

I'm quite happy with coordinates being decoded to `timedelta64`, but I'd love to have the option to *not* decode time interval in data variables.

Is there any plan to come back to this? And would the preferred solution still be the abovementioned one?

I'll need to spend some effort fixing our use case, possibly with a horrible work-around, so depending on the complexity of the preferred solution, I may be able to work on a PR for *xarray* instead.","{""total_count"": 1, ""+1"": 1, ""-1"": 0, ""laugh"": 0, ""hooray"": 0, ""confused"": 0, ""heart"": 0, ""rocket"": 0, ""eyes"": 0}",,264321376
https://github.com/pydata/xarray/issues/1621#issuecomment-604516472,https://api.github.com/repos/pydata/xarray/issues/1621,604516472,MDEyOklzc3VlQ29tbWVudDYwNDUxNjQ3Mg==,26384082,2020-03-26T16:02:59Z,2020-03-26T16:02:59Z,NONE,"In order to maintain a list of currently relevant issues, we mark issues as stale after a period of inactivity

If this issue remains relevant, please comment here or remove the `stale` label; otherwise it will be marked as closed automatically
","{""total_count"": 0, ""+1"": 0, ""-1"": 0, ""laugh"": 0, ""hooray"": 0, ""confused"": 0, ""heart"": 0, ""rocket"": 0, ""eyes"": 0}",,264321376
https://github.com/pydata/xarray/issues/1621#issuecomment-339116478,https://api.github.com/repos/pydata/xarray/issues/1621,339116478,MDEyOklzc3VlQ29tbWVudDMzOTExNjQ3OA==,1217238,2017-10-24T20:12:32Z,2017-10-24T20:12:32Z,MEMBER,"OK, sounds like there is consensus on removing this. I would still like to there to be an option for doing this sort of decoding, because I'm sure *somebody* finds this useful (at least I did, back when I wrote it!).

In particular, it would be nice to have some way to round-trip the `timedelta64` dtype. A simple way to do this would be to recognize the attribute `dtype='timedelta64[ns]` (as an xarray-specific convention) and use that for decoding/encoding timedelta64 dtypes.

My suggested path forward:
1. Add decoding support for recognizing `dtype='timedelta64[ns]'` and decoding it into the NumPy dtype. We have some very similar examples already (e.g., for `dtype=bool`), so this should not be hard.
2. Write all timedelta64 dtype data in netCDF files by saving the `dtype` attribute instead of `units`.
3. Issue a `FutureWarning` about what's going on that is triggered whenever `unit='time_unit'` is detected.
4. In the next major release of xarray, stop decoding time units.

Anyone interested in taking this on? All the logic can be found in `xarray/conventions.py`.","{""total_count"": 1, ""+1"": 1, ""-1"": 0, ""laugh"": 0, ""hooray"": 0, ""confused"": 0, ""heart"": 0, ""rocket"": 0, ""eyes"": 0}",,264321376
https://github.com/pydata/xarray/issues/1621#issuecomment-339093278,https://api.github.com/repos/pydata/xarray/issues/1621,339093278,MDEyOklzc3VlQ29tbWVudDMzOTA5MzI3OA==,1872600,2017-10-24T18:50:21Z,2017-10-24T18:50:21Z,NONE,I vote for `1` also.  How many makes a quorum?   :smile_cat: ,"{""total_count"": 0, ""+1"": 0, ""-1"": 0, ""laugh"": 0, ""hooray"": 0, ""confused"": 0, ""heart"": 0, ""rocket"": 0, ""eyes"": 0}",,264321376
https://github.com/pydata/xarray/issues/1621#issuecomment-338406207,https://api.github.com/repos/pydata/xarray/issues/1621,338406207,MDEyOklzc3VlQ29tbWVudDMzODQwNjIwNw==,2443309,2017-10-21T14:31:20Z,2017-10-21T14:31:20Z,MEMBER,I don't have a strong opinion here but 1 seems best. ,"{""total_count"": 0, ""+1"": 0, ""-1"": 0, ""laugh"": 0, ""hooray"": 0, ""confused"": 0, ""heart"": 0, ""rocket"": 0, ""eyes"": 0}",,264321376
https://github.com/pydata/xarray/issues/1621#issuecomment-338405750,https://api.github.com/repos/pydata/xarray/issues/1621,338405750,MDEyOklzc3VlQ29tbWVudDMzODQwNTc1MA==,950575,2017-10-21T14:28:47Z,2017-10-21T14:28:47Z,CONTRIBUTOR,"> I have never found `timedelta64` indices to be particularly useful.

Same here. :+1: for `1`

PS: `2` could be the start of a nice ""CF-addon"" package for `xarray` but I don't think it should be in the `xarray` code.","{""total_count"": 0, ""+1"": 0, ""-1"": 0, ""laugh"": 0, ""hooray"": 0, ""confused"": 0, ""heart"": 0, ""rocket"": 0, ""eyes"": 0}",,264321376
https://github.com/pydata/xarray/issues/1621#issuecomment-338288175,https://api.github.com/repos/pydata/xarray/issues/1621,338288175,MDEyOklzc3VlQ29tbWVudDMzODI4ODE3NQ==,1197350,2017-10-20T18:33:22Z,2017-10-20T18:33:22Z,MEMBER,"I vote for 1, plus a verbose warning message.

I have never found `timedelta64` indices to be particularly useful.","{""total_count"": 2, ""+1"": 2, ""-1"": 0, ""laugh"": 0, ""hooray"": 0, ""confused"": 0, ""heart"": 0, ""rocket"": 0, ""eyes"": 0}",,264321376
https://github.com/pydata/xarray/issues/1621#issuecomment-338247940,https://api.github.com/repos/pydata/xarray/issues/1621,338247940,MDEyOklzc3VlQ29tbWVudDMzODI0Nzk0MA==,1217238,2017-10-20T15:57:14Z,2017-10-20T15:57:14Z,MEMBER,"> I understand the potential issue here, but I think Xarray should follow CF conventions for time, and only treat variables as time coordinates if they have valid CF time units (<time unit> since <date>).

Rich, I know you've been involved in CF conventions and standard names, but I don't think the CF conventions on time apply directly here. These are ""time difference"" units, which are a distinct type of quantity. And assuredly the period of a wave is a type of ""time difference"" as well -- it's just not one that is useful to decode into an array with dtype `np.timedelta64`. Really this is a limitation of the non-ideal support for units in the NumPy ecosystem.

Is there some other sort of metadata we could use to make this distinction of ""physical"" vs. ""human"" time differences? Now is a good time to make changes, since we are on the verge of making a major release (v0.10).

Throwing out some ideas, none of which I particularly like (but to be clear, I don't like the status quo either):
1. We could unilaterally stop automatic decoding into `timedelta64`. (We would need to add a separate helper function that could be called to do these conversions afterwards.)
2. We could add look-up tables that recognize `standard_name` attributes, either a white-list or black-list for `timedelta64` compatible variables. (This would be a first for xarray, and is not something I'm particularly looking forward to maintaining.) 
3. We could decode coordinates and data variables differently, only converting coordinates into `timedelta64`. (This is not entirely ideal either, since it's easy to switch between the two in xarray's data model.)","{""total_count"": 0, ""+1"": 0, ""-1"": 0, ""laugh"": 0, ""hooray"": 0, ""confused"": 0, ""heart"": 0, ""rocket"": 0, ""eyes"": 0}",,264321376
https://github.com/pydata/xarray/issues/1621#issuecomment-338172936,https://api.github.com/repos/pydata/xarray/issues/1621,338172936,MDEyOklzc3VlQ29tbWVudDMzODE3MjkzNg==,1872600,2017-10-20T10:46:53Z,2017-10-20T10:50:18Z,NONE,"On https://stackoverflow.com/a/46675990/2005869, @shoyer explains: 
> My understanding of CF standard names is that `forecast_period` should be equal to the difference between time and `forecast_reference_time`, i.e., `forecast_period` = `time` - `forecast_reference_time`. If you specified your `time_offset` variable with units in the form ""hours"", then it would be decoded to `timedelta64`, along with `datetime64` for time and time_run, so xarray's arithmetic would actually satisfy this identity. You might find this useful if you only wanted to include two of these variables and wanted to calculate the third on the fly.   On the other hand, you probably don't want to convert the `Tper` variable to `timedelta64`. Technically, it is also a time period, but it's not a variable that makes sense to compare to time.

I understand the potential issue here, but I think Xarray should follow [CF conventions for time](http://cfconventions.org/Data/cf-conventions/cf-conventions-1.7/cf-conventions.html#time-coordinate), and only treat variables as time coordinates if they have valid CF time units (`<time unit> since <date>`).     

We know of thousands of datasets  (every dataset with waves!) where the current Xarray behavior is a problem. ","{""total_count"": 1, ""+1"": 1, ""-1"": 0, ""laugh"": 0, ""hooray"": 0, ""confused"": 0, ""heart"": 0, ""rocket"": 0, ""eyes"": 0}",,264321376
https://github.com/pydata/xarray/issues/1621#issuecomment-335609801,https://api.github.com/repos/pydata/xarray/issues/1621,335609801,MDEyOklzc3VlQ29tbWVudDMzNTYwOTgwMQ==,4701070,2017-10-10T21:12:50Z,2017-10-10T21:12:50Z,NONE,"Thanks @shoyer. I understand the issue better now. Had not considered timedeltas. That does conflate the issue. No sure-fire solution, then, so I'll continue with the workaround. Cheers.","{""total_count"": 0, ""+1"": 0, ""-1"": 0, ""laugh"": 0, ""hooray"": 0, ""confused"": 0, ""heart"": 0, ""rocket"": 0, ""eyes"": 0}",,264321376
https://github.com/pydata/xarray/issues/1621#issuecomment-335608148,https://api.github.com/repos/pydata/xarray/issues/1621,335608148,MDEyOklzc3VlQ29tbWVudDMzNTYwODE0OA==,1217238,2017-10-10T21:06:30Z,2017-10-10T21:06:30Z,MEMBER,"Thanks for filing an issue -- I usually follow the xarray tag on StackOverflow but missed this one.

I wrote an answer on StackOverflow to explain why this works this way and how to work around it, but as I say in my answer although this is intended behavior I'm open to ideas for improvement. You are not the first person to complain about this, specifically for handling of wave periods. See https://github.com/pydata/xarray/issues/843 and links therein for prior discussion (CC @ocefpaf).","{""total_count"": 1, ""+1"": 1, ""-1"": 0, ""laugh"": 0, ""hooray"": 0, ""confused"": 0, ""heart"": 0, ""rocket"": 0, ""eyes"": 0}",,264321376