Unable to deserialize DateTime<Tz>

[ctsrc]

Using Rust 1.81.0:

rustup show active-toolchain -v

stable-aarch64-apple-darwin (default)
rustc 1.81.0 (eeb90cda1 2024-09-04)

cargo --version

cargo 1.81.0 (2dbb1af80 2024-08-20)

Minimal repro:

File Cargo.toml:

[package]
name = "repro"
version = "0.1.0"
edition = "2021"

[dependencies]
chrono = { version = "0.4.38", features = ["serde"] }
chrono-tz = { version = "0.10.0", features = ["serde"] }
serde = { version = "1.0.210", features = ["derive"] }

File src/main.rs:

use chrono::DateTime;
use chrono_tz::Tz;
use serde::{Deserialize, Serialize};

#[derive(Debug, Serialize, Deserialize)]
struct Foo {
    bar: DateTime<Tz>,
}

fn main() {
    println!("Hello, world!");
}

Build fails:

cargo build

[...]
error[E0277]: the trait bound `DateTime<Tz>: Deserialize<'_>` is not satisfied
    --> src/main.rs:7:10
     |
7    |     bar: DateTime<Tz>,
     |          ^^^^^^^^^^^^ the trait `Deserialize<'_>` is not implemented for `DateTime<Tz>`
     |
     = note: for local types consider adding `#[derive(serde::Deserialize)]` to your `DateTime<Tz>` type
     = note: for types from other crates check whether the crate offers a `serde` feature flag
     = help: the following other types implement trait `Deserialize<'de>`:
               DateTime<FixedOffset>
               DateTime<Local>
               DateTime<Utc>
note: required by a bound in `next_element`
    --> /Users/user/.cargo/registry/src/index.crates.io-6f17d22bba15001f/serde-1.0.210/src/de/mod.rs:1732:12
     |
1730 |     fn next_element<T>(&mut self) -> Result<Option<T>, Self::Error>
     |        ------------ required by a bound in this associated function
1731 |     where
1732 |         T: Deserialize<'de>,
     |            ^^^^^^^^^^^^^^^^ required by this bound in `SeqAccess::next_element`
[...]

Am I doing something wrong?

The docs seem to indicate that Deserialize is supposedly implemented for Tz:

https://docs.rs/chrono-tz/0.10.0/chrono_tz/enum.Tz.html#impl-Deserialize%3C'de%3E-for-Tz

[ctsrc]

Related issue: #45

On first reading of that issue I thought it was a slightly different situation there.

But upon reading that issue again, I see that it's about this exact kind of thing.

Closing mine as duplicate.