we should also consider the configuration for these data types.

• the fixed-length data types must all be parametrized by their length in bytes (or bits)
• the datetime64 dtype is parametrized by the unit, which is a string defined here

I think the names are ok. The spec documents should definitely contain the configuration params. The spec doc should also contain information about how these dtypes can be (de)serialized, i.e. what array-bytes codecs supports them and how.

Why is - used in the extension name rather than underscore _ here?

because datetime64 and timedelta64 are so numpy-specific, I am wondering if we want to make this explicit in the name, e.g. by using the names numpy.datetime64, numpy.timedelta64.

If we ever create a solution for dates that doesn't rely on numpy semantics, we will have to tell people "don't use datetime64, that's actually just for numpy compatibility, use <better datetime data type> instead" which might get tedious and confuse users.

I think the most feasible alternative is an arrow timestamp. Both are based on a 64-bit integer primitive type. The main difference is

• arrow timestamp only allows milliseconds, microseconds, or nanoseconds as units
• arrow timestamp optionally includes timezone

We could imagine having both numpy.datetime64 and arrow.timestamp in Zarr. So I would not be opposed to the numpy. prefix.

Side note: every time I read about Arrow dtypes I feel a strong feeling that we are reinventing the wheel here in Zarr world. The concepts of "physical layout," "primitive type," and "parametric type" would be very useful for us.