The derive fills `updated_at` on an update whenever the form leaves it unset,
and it filled it with `timestamp_millis()`. Every hand-written caller stamps
these columns from a seconds clock, and `created_at` is not auto-filled at
all, so a single INSERT-then-UPDATE left one row carrying `created_at` in
seconds and `updated_at` in milliseconds.
Nothing errors - the column is a bare i64 - so the rows quietly stop being
comparable, and anything ordering, diffing or syncing on `updated_at` reads an
auto-stamped row as roughly 56,000 years in the future.
Found in Leptin on 2026-09-06 across 9 tables and 4152 rows, including 33 of
34 meals, and only because two columns on one row disagreed. Michael: "make
this a default on sqlx-record-derive, seconds should be default."
Seconds is the DEFAULT, not an override: a caller that sets updated_at itself
still wins, so paths that already stamp deliberately are unaffected.
Guarded by tests over the emitting source - the bug is a unit, not a
behaviour, and a DB-backed test would need a fixture for something a string
comparison settles exactly. Verified non-vacuous.
Consumers should repair existing rows: any updated_at > 1e11 is milliseconds
and divides by 1000.
8093a8faab