diff --git a/docs/blog/posts/3.1.0-data-types.md b/docs/blog/posts/3.1.0-data-types.md
new file mode 100644
index 0000000000..a211ce956e
--- /dev/null
+++ b/docs/blog/posts/3.1.0-data-types.md
@@ -0,0 +1,299 @@
+---
+date: 2025-07-14
+authors:
+  - d-v-b
+categories:
+  - Release
+---
+
+# New data types in Zarr-Python 3.1.0
+
+!!! note
+    This post was written for the 3.1.0 release in July 2025. The code examples run against the current release of Zarr-Python.
+
+The [3.1.0 release](../../release-notes.md#310-2025-07-14) of Zarr-Python overhauls our internal model of array data types. This is exciting for two reasons:
+
+First, we added Zarr V3 support for a lot of NumPy data types, including datetimes, timedeltas, fixed-length Unicode strings, null-terminated bytes, raw bytes, and structured data types. This unblocks Zarr V2 users who couldn't migrate to Zarr V3 until these data types were added.
+
+Second, Zarr-Python data types are now *extensible*. If you have a NumPy-compatible data type class that Zarr-Python doesn't already support, like [`bfloat16`](https://github.com/jax-ml/ml_dtypes?tab=readme-ov-file#bfloat16), you can define a Zarr data type that wraps that data type! Here's a [self-contained, executable example](https://github.com/zarr-developers/zarr-python/blob/main/examples/custom_dtype/custom_dtype.py) that walks through the entire process.
+
+<!-- more -->
+
+There's more to the data type extensibility story than just implementing a new data type in Zarr-Python. A widely-used data type should have a *published standard* so different Zarr libraries can all consistently implement that data type.
+
+That's why the Zarr community has created the [zarr-extensions](https://github.com/zarr-developers/zarr-extensions/) project. `zarr-extensions` is a central repository for community-defined data types (and other extensions to the Zarr data model, like codecs and chunk grids). Check out the [specification document](https://github.com/zarr-developers/zarr-extensions/tree/main/data-types/bfloat16) for the `bfloat16` data type for an example.
+
+To dive right into this new feature, head over to our new [data type documentation page](../../user-guide/data_types.md) and read more about how this new data type system works in Zarr-Python.
+
+But perhaps you'd like to know more about the *context* for this new feature. The best way to convey that is to answer the following two questions:
+
+- What is Zarr's "data type model" anyway?
+- How did we make data types extensible in Zarr-Python? And why now?
+
+That's what the rest of this post is about.
+
+## Zarr's data type model
+
+This section explains how data types used to be declared in Zarr V2, why we did it that way, why that turned out to be problematic, and how we improved things in Zarr V3.
+
+### NumPy x Zarr
+
+The Zarr format and the Zarr-Python library are heavily influenced by NumPy's approach to arrays and data types. NumPy's influence is even written explicitly into the Zarr V2 specification:
+
+> Simple data types are encoded within the array metadata as a string,
+> following the [NumPy array protocol type string (typestr) format](https://numpy.org/doc/stable/reference/arrays.interface.html#the-array-interface-protocol).
+>
+> -- [The Zarr V2 spec](https://zarr-specs.readthedocs.io/en/latest/v2/v2.0.html#data-type-encoding)
+
+On the implementation side, Zarr-Python uses NumPy internally, and we expose Zarr array data to users in the form of NumPy arrays or arrays that follow the NumPy API (like [cupy arrays](https://docs.cupy.dev/en/stable/reference/ndarray.html)).
+
+In some areas Zarr and NumPy fit together very well. They both describe arrays, after all. But the two projects have *very* different scopes: typical NumPy arrays live in memory of a single Python program. Zarr arrays are often persisted to external storage and accessed by many different programs, in many different programming languages, over many years.
+
+In my opinion, these fundamentally divergent design goals limit how much Zarr can borrow directly from NumPy.
+
+One of the big changes in the Zarr V3 spec was dropping NumPy compatibility in its data type definition. To explain this choice, the next section will show just how tightly coupled Zarr V2 was to NumPy, and how this was ultimately problematic.
+
+### NumPy's influence on Zarr V2
+
+Every Zarr V2 array is defined by a JSON metadata document. This document declares the information necessary to read from the array, including the array's shape, data type, chunks, etc. All of that metadata must be JSON serializable.
+
+For data types in particular, the Zarr V2 format defined a JSON serialization scheme that simply copied a particular[^1] string representation of NumPy data types. This is demonstrated in the following example:
+
+```python exec="true" session="blog-310-v2-dtype" source="above" result="ansi"
+import numpy as np
+import zarr
+import pprint
+
+dtype_str = '<c16'
+
+# make a numpy array
+np_data = np.array([0 + 1j, 1 + 1j, 2 + 3j], dtype=dtype_str)
+
+# make a zarr v2 array from our numpy array
+z_data = zarr.from_array({}, data=np_data, zarr_format=2)
+
+meta_dict = z_data.metadata.to_dict()
+
+# check out the metadata document
+print(pprint.pformat(meta_dict, sort_dicts=False))
+```
+
+```python exec="true" session="blog-310-v2-dtype" source="above" result="ansi"
+# The numpy .str attribute is the same
+# as the dtype field in Zarr V2 metadata
+print(np_data.dtype.str == meta_dict["dtype"])
+```
+
+There are some advantages to copying NumPy data type strings:
+
+- Strings are JSON serializable. We can easily store these NumPy strings in Zarr metadata documents without defining a special JSON serialization procedure.
+- Using NumPy strings gives Zarr easy NumPy compatibility -- we can just call `np.dtype` on the string to get the right NumPy data type.
+
+If Zarr only supported integers and floating point numbers, maybe the story could end here. But Zarr V2 supports other data types, namely variable-length data types (because Zarr V2 users *needed* these data types), and with these data types we see the limits of copying strings from NumPy.
+
+#### Variable-length data types
+
+The biggest problem with using NumPy data type strings in Zarr is that *distinct Zarr data types have the same NumPy string representation*. In other words, there are more Zarr data types than NumPy data types.
+
+When Zarr V2 was defined, years before NumPy 2.0, NumPy had no data type for an array of strings with variable length, like `["a", "bb", "ccc"]`. NumPy supported these arrays with the ["Object" data type](https://numpy.org/doc/stable/reference/arrays.scalars.html#numpy.object_), which supports arrays of arbitrary Python objects (including strings) by storing a buffer of references.
+
+The "Object" data type has a string identifier of `"|O"`, and "Object" data type arrays can contain *any* Python object, including but not limited to variable length strings. So two object arrays with very different contents will have the same data type identifier:
+
+```python exec="true" session="blog-310-object-dtype" source="above" result="ansi"
+import numpy as np
+
+vlen_str = np.array(["a", "bb"], dtype="O")
+vlen_array = np.array([[0], [1,2]], dtype="O")
+
+print(vlen_str.dtype.str)
+print(vlen_array.dtype.str)
+```
+
+The above example is relevant because Zarr-Python 2 supported arrays of variable length strings *and* arrays of variable length arrays. Zarr-Python 2 declared both of these distinct data types as `"dtype": "|O"` in metadata documents (because they are both the "same" data type from NumPy's POV), even though `"O"` is not one of the type codes defined in the [Zarr V2 spec](https://zarr-specs.readthedocs.io/en/latest/v2/v2.0.html#data-type-encoding).
+
+This is clearly a problem. From a Zarr point of view a variable-length array of strings is *very different* from a variable-length array of arrays. Zarr needs to store arrays on disk, and the storage procedure is very different for these two distinct data types.
+
+Zarr-Python solved this with a hack: an array of variable-length strings was *operationally* defined as an array with the following configuration in metadata:
+
+- the data type is declared as `"|O"`.
+- the chunk encoding for the array included a special "variable-length UTF8" codec. This could be found either in the `filters` field or the `compressor` field.
+
+And an array of variable-length arrays was operationally defined similarly, although with a *different* special codec (one designed specifically for variable-length arrays).
+
+Clearly it's problematic if the metadata field responsible for declaring the data type for the array (`dtype`) doesn't fully declare the data type for the array in some cases! Zarr-Python hacked around this by storing some data-type-specific information in the filters / compressor for an array, but this is far from ideal (and this behavior was never fully specified).
+
+### Zarr Version 3
+
+Coupling Zarr's data type definition to an implementation detail of a particular (albeit, highly significant) Python library like NumPy proved a limiting choice for Zarr V2. Wisely, the authors of the Zarr V3 spec chose not to define array data types by copying a detail of NumPy's API.
+
+Instead, data types in Zarr V3 are declared in one of two ways:
+
+- as a string, like `"int64"`, which declares the signed 64-bit integer data type. Note that unlike NumPy, Zarr V3 data types are generally not defined with a byte order.
+- as a JSON object with the following form:
+
+    ```text
+    {
+     "name": <data type name>,
+     "configuration": {...<data type configuration>}
+    }
+    ```
+
+This brings immediate advantages over the Zarr V2 data type model.
+
+#### Extensible data types
+
+Instead of copying NumPy, the Zarr V3 specification defines a list of core data types that all Zarr implementations ought to support. But we also think people should be able to create new data types, and we don't want to update the core Zarr V3 specification every time that happens.
+
+That's the job of the [zarr-extensions](https://github.com/zarr-developers/zarr-extensions/) project mentioned above. It is a lightweight coordination mechanism that ensures people designing their own data types can avoid name collisions with other pre-existing community-defined data types.
+
+We also think writing data type specifications in the open will drive awareness and adoption of new data types across multiple Zarr implementations.
+
+#### Using more of JSON
+
+By ditching the Zarr V2 string-only data type definition, we can use JSON objects to more explicitly model data types that have significant parametrization.
+
+For example, NumPy defines [two data types](https://numpy.org/doc/stable/reference/arrays.datetime.html) for temporal *moments* (`datetime64`) and *durations* (`timedelta64`). Both of these data types are parametrized by a time unit and a scaling factor. Zarr V2 used the NumPy string representation of these data types, leading to [stringly typed](https://www.hanselman.com/blog/stringly-typed-vs-strongly-typed) data type declarations like `"<M8[10ns]"`, which encodes a little-endian `datetime64` with a scale factor of 10 and a unit of nanoseconds.
+
+In Zarr V3, we use a much more explicit representation to express the same data type:
+
+```json
+{
+    "name": "numpy.datetime64",
+    "configuration": {"scale_factor": 10, "unit": "ns"}
+}
+```
+
+This JSON object is defined in a [published specification](https://github.com/zarr-developers/zarr-extensions/tree/main/data-types/numpy.datetime64) for this data type, which ensures that someone implementing this data type in a different programming language has a clear point of reference. Which brings us to the last point: ensuring interoperability.
+
+#### Ensuring interoperability
+
+Defining Zarr data types in-house is good for Zarr implementations today, but we think it's also the right choice for data consumers in the future.
+
+If the Zarr V3 spec still used NumPy's data type strings, the Zarr ecosystem would be vulnerable to a scenario in which NumPy changes how they represent data types, which could complicate reading Zarr data written in the past.
+
+That's enough about the spec story. Now we'll shift gears and talk about how we finally embraced the Zarr V3 data type model in the 3.1 release of Zarr-Python.
+
+## What's changed in Zarr-Python 3.1.0
+
+We shipped [Zarr-Python 3.0](https://zarr.dev/blog/zarr-python-3-release/) back in January with support for a fixed set of array data types. To get the 3.0 release out quickly, we made a lot of short-term design choices, like handling data types for Zarr V2 arrays and Zarr V3 arrays in completely separate code paths. We also relied heavily on NumPy data type classes internally.
+
+This was fast to ship, but it proved expensive in terms of technical debt -- separate code paths for V2 and V3 arrays led to code duplication, and worse, we introduced a lot of unnecessary complexity for operations that could, in principle, be represented more simply.
+
+There were other problems -- Zarr-Python 3.0 did not ship with Zarr V3 support for a few important Zarr V2 / NumPy data types, namely datetimes, timedeltas, fixed-length UTF-32 strings, fixed-length bytes, and structured data types. People who had used these data types with Zarr-Python 2.x could not migrate to Zarr V3 until we added support for these data types.
+
+So while squashing a lot of the urgent post-3.0-release bugs, we started thinking about a coherent, extensible model for data types, since it was clear that we couldn't commit to longer-term maintenance for our initial data type model.
+
+Things got a lot more real in late January when [Nick Byrne](https://github.com/nenb/), an engineer at [OpenTeams](https://openteams.com/), drafted a [concrete proposal](https://github.com/zarr-developers/zarr-python/pull/2750) for a new data type API.
+
+Nick's proposal was hugely influential; when [Earthmover](https://earthmover.io/) contracted me to add fixed-length strings to Zarr-Python, I realized that the total cost of adding a new data type to our existing data type API would, over the long term, cost more time than a full re-design. So I started work on a [pull request](https://github.com/zarr-developers/zarr-python/pull/2874) that extended Nick's ideas to as many data types as possible.
+
+Through the 300+ comments on that pull request, and many more comments in the associated [discussion on the Zarr developer chat](https://ossci.zulipchat.com/#narrow/channel/423692-Zarr/topic/extensible.20dtypes), we built an API that's pretty good, or at least it's good enough for now :sweat_smile:.
+
+### ZDType
+
+The basic design revolves around one class per data type. Each Zarr data type class, or `ZDType`, relates two other distinct Python types:
+
+- The *"native" data type*
+
+    This is the in-memory data type Zarr-Python will use when returning decoded chunks of a Zarr array to users. Right now all the native data types are NumPy data types (CuPy arrays use NumPy data types too), but hopefully we support more array backends in the future!
+
+- The *scalar type*
+
+    This is the type of the individual elements inside an array.
+
+    To illustrate how this type is not the same as the "native" data type, consider the variable-length string data type. With older versions of NumPy, the native data type is the NumPy "Object" data type; with newer versions of NumPy, we can use the [variable-length string data type](https://numpy.org/doc/stable/user/basics.strings.html#variable-width-strings). But in either case the scalar type is `str`: a plain Python string.
+
+Each `ZDType` defines the following behaviors:
+
+- Creating an appropriate native data type
+- Reading from an appropriate native data type
+- Creating Zarr V2 and Zarr V3-compatible data type metadata
+- Reading Zarr V2 and Zarr V3-compatible data type metadata
+- Encoding and decoding scalar values from Zarr V2 and Zarr V3 metadata.
+
+    This is necessary because many data types use special JSON serialization schemes for scalar values that are stored in the `"fill_value"` field in array metadata.
+
+- Casting in-memory Python objects to scalar values
+
+We can demonstrate everything with a simple example:
+
+```python exec="true" session="blog-310-dtype-api" source="above" result="ansi"
+import numpy as np
+from zarr.dtype import DateTime64
+
+npd = np.dtype('datetime64[10ns]')
+zd = DateTime64.from_native_dtype(npd)
+
+print(zd)
+```
+
+```python exec="true" session="blog-310-dtype-api" source="above" result="ansi"
+print(zd.to_native_dtype() == npd)
+```
+
+```python exec="true" session="blog-310-dtype-api" source="above" result="ansi"
+# The "name" key is what we will actually
+# write to Zarr V2 metadata.
+print(zd.to_json(zarr_format=2))
+```
+
+```python exec="true" session="blog-310-dtype-api" source="above" result="ansi"
+print(zd.to_json(zarr_format=3))
+```
+
+```python exec="true" session="blog-310-dtype-api" source="above" result="ansi"
+print(zd.cast_scalar(10))
+```
+
+```python exec="true" session="blog-310-dtype-api" source="above" result="ansi"
+print(zd.from_json_scalar(10, zarr_format=3))
+```
+
+Adding a new data type to Zarr-Python is now as simple as implementing a new `ZDType` class and registering it. That whole process is demonstrated in [this self-contained example](https://github.com/zarr-developers/zarr-python/blob/main/examples/custom_dtype/custom_dtype.py).
+
+And that's pretty much it -- each `ZDType` defines an interface between the Zarr V2 / V3 metadata representations on one side, and in-memory python objects on the other. `ZDType` classes can be added at runtime by users, and we can ship more `ZDType` classes with Zarr-Python as more community data types are minted.
+
+### New (old) data types
+
+Zarr-Python 3.0 shipped without all the data types that Zarr-Python 2.x supported. Zarr-Python 3.1 adds full support for these data types, across Zarr V2 and V3:
+
+- [Fixed-length raw bytes][zarr.dtype.RawBytes]
+- [Fixed-length null-terminated bytes][zarr.dtype.NullTerminatedBytes]
+- [Fixed-length UTF-32 strings][zarr.dtype.FixedLengthUTF32]
+- [Datetime64][zarr.dtype.DateTime64]
+- [Timedelta64][zarr.dtype.TimeDelta64]
+- [Structured data types][zarr.dtype.Structured]
+
+For the full list of supported data types, see the [Zarr-Python docs](../../user-guide/data_types.md#list-of-data-types).
+
+## What's next
+
+The Zarr V2 data type model incidentally made NumPy a soft dependency for the entire Zarr ecosystem. This proved problematic for a data format implemented in multiple languages, and it ultimately limited our ability to define new data types.
+
+The Zarr V3 spec fixed this with a *de novo* extensible data type model, but Zarr-Python didn't fully implement that model until Zarr-Python version 3.1. With Zarr-Python 3.1 released, and the `zarr-extensions` project up and running, we're very excited to see what the Zarr community does with these long-awaited features.
+
+In the short term, we hope machine learning engineers use data types like `bfloat16` to take full advantage of Zarr for cloud-friendly, scalable array storage.
+
+Longer term, there are some features we could add to the Zarr data type model.
+
+One common user request is a framework for declaring *nullable* data types, i.e. data types that combine a conventional data type with an optional value. This greatly simplifies the expression of arrays with missing data.
+
+Another feature would be a data type model that allowed readers to *partially* support a data type.
+
+For both of these features, the [Apache Arrow data type model](https://arrow.apache.org/docs/format/Columnar.html#data-types) looks very enticing. Arrow supports nullable data types, and defines behaviors for partially-supported data types. What would it take for Zarr to include Arrow buffers as an alternative array backend?
+
+## Who supported this
+
+Several groups of people contributed resources that enabled this work.
+
+The [Zarr spec contributors](https://github.com/zarr-developers/zarr-specs/graphs/contributors) did the foundational work of delivering a Zarr V3 specification that made this work expressible.
+
+The [Zarr-Python contributors](https://github.com/zarr-developers/zarr-python/graphs/contributors) built the foundational Zarr implementation in Python, and provided extensive feedback during the development process of the work described in this post.
+
+[OpenTeams](https://openteams.com/) supported Nick Byrne's invaluable work as a PR reviewer.
+
+[Earthmover](https://earthmover.io/) supported my work on the first half of this project, and [Development Seed](https://developmentseed.org/) supported the culmination.
+
+We are immensely grateful to the folks at all of these orgs who made this happen!
+
+[^1]: I say "particular" because NumPy supports multiple string representations of the same data type. NumPy interprets `"|b1"`, `">b1"`, `"<b1"`, `"=b1"`, `"bool"` as declarations of the same boolean data type.