fix(mysql): infer DATE/DATETIME/TIMESTAMP columns as nullable in query!/query_as! to handle zero dates

[Ar-maan05]

Does your PR solve an issue?

Fixes #4283

Is this a breaking change?

Yes: this is a behavior change to compile-time type inference for the query! family of macros, so it should land in the next major release (0.10.0).

query!/query_as!/query_scalar! now infer MySQL DATE, DATETIME, and TIMESTAMP columns as nullable (Option<T>) even when the column is declared NOT NULL. Existing code that binds such a column to a non-Option field/struct will need either to use Option<T> or to opt out with the ! column override (e.g. SELECT created_at AS "created_at!"). TIME and non-temporal columns are unaffected.

---

Problem

Against a MySQL NOT NULL TIMESTAMP/DATETIME/DATE column that contains a "zero date" (0000-00-00 00:00:00), query_as! fails at runtime with UnexpectedNullError:

CREATE TABLE events (
    id         BIGINT UNSIGNED AUTO_INCREMENT PRIMARY KEY,
    updated_at TIMESTAMP NOT NULL DEFAULT '0000-00-00 00:00:00'
);
INSERT INTO events VALUES ();  -- updated_at is now 0000-00-00 00:00:00

Root cause

The runtime is internally consistent and intentionally treats a zero date as NULL: MySqlValueRef::is_null() (sqlx-mysql/src/value.rs) maps zero DATE/DATETIME/TIMESTAMP values to NULL, so Option<NaiveDateTime> already decodes them to None (and a non-Option decode yields UnexpectedNullError, asserted by test_type_chrono_zero_date). This was deliberate (08247237 "handle zero dates in MySQL, emit as Option::None (treat as NULL)").

The gap is in macro nullability inference: describe() in sqlx-mysql/src/connection/executor.rs derived nullability purely from the NOT_NULL column flag. So a NOT NULL temporal column was inferred non-nullable, the macro generated a bare NaiveDateTime field, and a zero date then decoded as a "null" into a non-Option field -> UnexpectedNullError. MySQL has no other nullability path (unlike Postgres' EXPLAIN-based refinement), so this one site is authoritative.

Fix

Treat DATE/DATETIME/TIMESTAMP columns as nullable in inference regardless of NOT_NULL, matching the exact type set that is_null() already maps to NULL. The macros now emit Option<T> for these columns, which decodes both real values (Some) and zero dates (None) correctly. TIME is excluded because it has no zero value that maps to NULL.

Tests

• tests/mysql/describe.rs: new it_describes_temporal_not_null_as_nullable asserting DATE/DATETIME/TIMESTAMP NOT NULL infer as nullable while TIME NOT NULL and INTEGER NOT NULL stay non-nullable; updated it_describes_simple for the created_at TIMESTAMP column.
• tests/mysql/macros.rs: updated test_uuid_is_compatible_mariadb (created_at → Option<OffsetDateTime>).

Alternative considered

A sql_mode-aware variant, only inferring nullable when the session actually permits zero dates (NO_ZERO_DATE/NO_ZERO_IN_DATE off), would avoid the ergonomic cost for strict-mode users. I went with the unconditional rule because it's always safe, whereas the sql_mode approach can still produce a runtime UnexpectedNullError when the compile-time DB is strict but production is permissive. Happy to switch if you'd prefer the narrower behavior.

[Ar-maan05]

The one red check: Postgres SSL Auth (17, async-std, native-tls), is an unrelated CI infrastructure flake, not a test failure. The job failed at the setup step:

Run docker compose -f tests/docker-compose.yml run -d -p 5432:5432 --name postgres_17_client_ssl postgres_17_client_ssl

i.e. the Postgres SSL container failed to start before any test ran. This PR is MySQL-only (the diff touches sqlx-mysql + tests/mysql + CHANGELOG.md), and every job that actually exercises the change, all MySQL/MariaDB functional & integration jobs, Format, and the full Check matrix, is green.

Happy to push a rebase/empty commit to re-trigger CI if that's easier than a re-run on your end.