Thank you for opening this pull request! It may take us a few days to respond here, so thank you for being patient.
If you have questions, some answers may be found in ourcontributing guidelines.

Would these changes also work for cf timedeltas or are they going to still cause problems?
I'm tempted to write a script to bash through all the ACCESS-NRI intake datastores and see if there's anything else in there that's dtype object — let me know if this would be useful, or if we should just wait for it to break later

Would these changes also work for cf timedeltas or are they going to still cause problems? I'm tempted to write a script to bash through all the ACCESS-NRI intake datastores and see if there's anything else in there that's dtype object — let me know if this would be useful, or if we should just wait for it to break later

If you can find something thats specifically a cftimedelta and run the_contains_cftime_datetimes function on it that'd be super helpful to know whether it returns True or False.

TLDR: don't mind me, it's not going to cause any issues

Firstly, what I thought was a cftimedelta turned out to be a numpy timedelta hanging out with a cftime

When I did manage to coerce this timedelta into cftime conventions, it just contained a floating point number of days, so I can't see anything having issues with its size

coder=xr.coding.times.CFTimedeltaCoder()result=coder.encode(oops.average_DT).load()print(result.dtype)result

I did some prodding around yesterday and I realised this won't let us do something like

importxarrayasxrcftime_datafile="/path/to/file.nc"xr.open_dataset(cftime_datafile,chunks='auto')

yet, only stuff along the lines of

importxarrayasxrcftime_datafile="/path/to/file.nc"ds=xr.open_dataset(cftime_datafile,chunks=-1)ds=ds.chunk('auto')

I think implementing the former is going to be a bit harder, but I'm starting to clock the code structure a bit more now so I'll have a decent crack.

Why so? Are we sending"auto" in tonormalize_chunks first?