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-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-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-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 (