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/5402#issuecomment-853900455,https://api.github.com/repos/pydata/xarray/issues/5402,853900455,MDEyOklzc3VlQ29tbWVudDg1MzkwMDQ1NQ==,20629530,2021-06-03T14:11:16Z,2021-06-03T14:11:16Z,CONTRIBUTOR,"Agreed that this is limited and there's need for a more general solution!

However, this problem is quite tricky...
The best I see is what I think you suggested in the other thread : special workaround with re-casting when the operation involves ""<m8[ns]"" and ""O""  (and that the ""O"" is cftime datetimes). That clears the instability problem of my solution. It loads a value, so dask-compat is not optimal, but that's already what `dt` does.

The encoding problem remains, but I made some tests and I realized numpy automatically casts timedeltas to the smallest unit, but accepts operations between timedeltas of different units. Could we accept `timedelta64` arrays with another units than ""ns""? Then, there could be a check when converting python timedeltas : if nanosecond information exist : go with [ns], if not, go with  [ms]. This bumps the limit from 292 years to 292471. And, with this relaxation of the dtype strictness, would allow a user to use even coarser frequencies if need be. 

Throwing ideas. There might be other issues that I did not see!
","{""total_count"": 0, ""+1"": 0, ""-1"": 0, ""laugh"": 0, ""hooray"": 0, ""confused"": 0, ""heart"": 0, ""rocket"": 0, ""eyes"": 0}",,906175200