Specification for datetime dtypes is ambiguous

[shoyer]

The zarr docs state that datetime and timedelta types are supported, but doesn't specify a fixed time resolution. Without that, the character code is ambiguous.

We should fix this either by indicating a single, fixed time resolution or removing date/time types altogether.

Unfortunately, different systems default to different time resolutions (e.g., us for numpy vs ns for pandas). Given this ambiguity, I would opt to remove date/time types from the spec, and let zarr focus solely on physical rather than logical dtypes.

[alimanfoo]

Thanks @shoyer, I have no experience of using either dtype so very happy to defer to your judgement here.

[alimanfoo]

Just looking at this, datetime64 is kind-of supported at the moment but it's a mess. There is an issue (https://github.com/alimanfoo/numcodecs/issues/39) that prevents buffer access to a datetime64 array, which can be worked around with a filter, e.g.:

In [34]: a = np.array(['2007-07-13', '2006-01-13', '2010-08-13'], dtype='datetime64[D]')

In [35]: z = zarr.array(a, fill_value=None, filters=[numcodecs.AsType('i8', a.dtype)])

In [36]: z[:]
Out[36]: array(['2007-07-13', '2006-01-13', '2010-08-13'], dtype='datetime64[D]')

Also currently requires fill_value=None otherwise get a JSON serialization exception.

I think I will remove these from the spec for now, and also raise a ValueError if some tries to create an array with datetime or timedelta dtype explaining the situation.