What happened:

In an environment with xarray 0.18.0 and dask 2021.05.0 installed, I saved a dataset using to_zarr, opened it again using open_zarr, and called map_blocks on one of its variables. I got the following traceback:

Traceback (most recent call last): File "/home/pont/./dasktest2.py", line 12, in <module> ds2.myvar.map_blocks(lambda block: block) File "/home/pont/loc/envs/xcube-repos/lib/python3.9/site-packages/xarray/core/dataarray.py", line 3770, in map_blocks return map_blocks(func, self, args, kwargs, template) File "/home/pont/loc/envs/xcube-repos/lib/python3.9/site-packages/xarray/core/parallel.py", line 565, in map_blocks data = dask.array.Array( File "/home/pont/loc/envs/xcube-repos/lib/python3.9/site-packages/dask/array/core.py", line 1159, in __new__ if layer.collection_annotations is None: AttributeError: 'dict' object has no attribute 'collection_annotations'

What you expected to happen:

I expected map_blocks to complete successfully.

Minimal Complete Verifiable Example:

```python import xarray as xr import numpy as np

ds1 = xr.Dataset({ "myvar": (("x"), np.zeros(10)), "x": ("x", np.arange(10)), })
ds1.to_zarr("test.zarr", mode="w") ds2 = xr.open_zarr("test.zarr") ds2.myvar.map_blocks(lambda block: block) ```

Anything else we need to know?:

I wasn't sure whether to report this issue with dask or xcube. With dask 2021.04.1 the example runs without error, and it seems that dask PR 7309 introduced the breaking change. But my understanding of xarray's map_blocks implementation isn't sufficient to figure out where exactly the bug lies.

Environment:

What happened:

I used xarray.open_dataset to open a NetCDF file whose time coordinate had the calendar attribute set to Gregorian. All dates were within the Timestamp-valid range.

The resulting dataset represented the time co-ordinate as a cftime._cftime.DatetimeGregorian.

What you expected to happen:

I expected the dataset to represent the time co-ordinate as a datetime64[ns], as documented here and here.

Minimal Complete Verifiable Example:

```python import xarray as xr import numpy as np import pandas as pd

def print_time_type(dataset): print(dataset.time.dtype, type(dataset.time[0].item()))

da = xr.DataArray( data=[32, 16, 8], dims=["time"], coords=dict( time=pd.date_range("2014-09-06", periods=3), reference_time=pd.Timestamp("2014-09-05"), ), )

Create dataset and confirm type of time

ds1 = xr.Dataset({"myvar": da}) print_time_type(ds1) # prints "datetime64[ns]" <class 'int'>

Manually set time attributes to "Gregorian" rather

than default "proleptic_gregorian".

ds1.time.encoding["calendar"] = "Gregorian" ds1.reference_time.encoding["calendar"] = "Gregorian" ds1.to_netcdf("test-capitalized.nc")

ds2 = xr.open_dataset("test-capitalized.nc") print_time_type(ds2)

prints "object <class 'cftime._cftime.DatetimeGregorian'>"

Workaround: add "Gregorian" to list of standard calendars.

xr.coding.times._STANDARD_CALENDARS.add("Gregorian") ds3 = xr.open_dataset("test-capitalized.nc") print_time_type(ds3) # prints "datetime64[ns]" <class 'int'> ```

Anything else we need to know?:

The documentation for the use_cftime parameter of open_dataset says:

If None (default), attempt to decode times to np.datetime64[ns] objects; if this is not possible, decode times to cftime.datetime objects.

In practice, we are getting some cftime.datetimes even for times which are interpretable and representable as np.datetime64[ns]s. In particular, we have some NetCDF files in which the time variable has a calendar attribute with a value of Gregorian (with a capital ‘G’). CF conventions allow this:

When this standard defines string attributes that may take various prescribed values, the possible values are generally given in lower case. However, applications programs should not be sensitive to case in these attributes.

However, xarray regards Gregorian as a non-standard calendar and falls back to cftime.datetime. If (as in the example) Gregorian is added to xr.coding.times._STANDARD_CALENDARS, the times are read as np.datetime64[ns]s.

Suggested fix: in xarray.coding.times._decode_datetime_with_pandas, change ‘if calendar not in _STANDARD_CALENDARS:’ to ‘if calendar.lower() not in _STANDARD_CALENDARS:’.

Environment: