[d-v-b]

🤖 AI text below 🤖

Fixed Zarr format 2 metadata written for generic time units: the v2 spec requires the unit of a datetime64 or timedelta64 dtype in brackets, but a generic-unit time dtype serialized as NumPy's unitless typestr (<M8). The generic unit is now written explicitly — <M8[generic], or <M8[2generic] with a scale, as scaled generic units already were — which NumPy parses back to the same dtype (np.dtype("M8[generic]") → generic datetime64). The unitless spellings stay readable as the generic unit, per zarr-developers#4580: acceptable for reading, not for writing.

Consequences a reviewer should weigh:

• The unitless spelling no longer round-trips verbatim: from_json("<M8") reads as the generic unit and writes back as <M8[generic]. A new test pins the read-acceptance and the write-normalization; the dtype fixture generator now brackets every unit.
• [generic] is bracketed and NumPy-parseable, but "generic" is not in the unit table the spec points to, so strict spec readers (including zarr-metadata's v2 reader, whose NUMPY_TIME_UNITS excludes it) still refuse it. Whether zarr-metadata should accept generic is left to avoid writing invalid zarr v2 datetime metadata zarr-developers/zarr-python#4580.

Fixes zarr-developers#4580

🤖 Generated with Claude Code

[d-v-b]

refactor the duplicated code into a shared routine

[d-v-b]

🤖 AI text below 🤖

The agent moved the bracketing into TimeDTypeBase._v2_name, which both to_json implementations now call (7541009).

[d-v-b]

either parametrize this test, or even better, fold it in to the existing dtype serialization tests (we might not have alias-aware tests, but we should probably add them)

[d-v-b]

🤖 AI text below 🤖

The agent folded the one-off test into the shared dtype wrapper as alias-aware cases: json_alias_v2_params on the test base takes (alias, canonical) pairs, asserting both spellings read as the same dtype and write the canonical one. The time types list the unitless generic spellings and NumPy's μs alias (3b6705e).