Cameron CordesandClaude Opus 5.5
e6ae1727cc
The first #160 migration cleared rows whose legacy date_taken_source was 'filename'. But the true-instant drain wrote only the new-contract triple, so rows with a correct legacy date (e.g. an exiftool container date) could still carry a filename-derived implausible year in date_utc. Prod has three: VID_<counter> videos dated 2095 / 2229 / 8580 whose containers say 2016 / 2017. Clear just the triple wherever date_utc is outside [1995, 2028) UTC; backfill_utc_dates re-resolves it with the gated matcher, and the frozen legacy pair is left alone. On prod those three are the only rows with date_utc out of range. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
18 lines
949 B
SQL
18 lines
949 B
SQL
-- #160 follow-up. The first fix (2026-10-16 migration) cleared rows whose
|
|
-- legacy `date_taken_source` was 'filename'. But the true-instant drain
|
|
-- (#118) re-ran the resolver over rows with a correct legacy date (e.g. an
|
|
-- exiftool container date) and wrote only the new-contract triple, so
|
|
-- some rows carry a filename-derived implausible year in `date_utc` while
|
|
-- their legacy pair says 'exiftool'. On prod: three VID_<counter> videos
|
|
-- (years 2095, 2229, 8580) whose containers say 2016/2017.
|
|
--
|
|
-- Clear just the triple on any row whose true instant is outside
|
|
-- [1995-01-01, 2028-01-01) UTC. `date_utc IS NULL` puts it back in
|
|
-- `backfill_utc_dates`, which re-resolves it with the gated matcher; the
|
|
-- legacy pair is left alone (it's frozen for rollback, and here correct).
|
|
UPDATE image_exif
|
|
SET date_utc = NULL,
|
|
camera_offset_minutes = NULL,
|
|
date_taken_tz_source = NULL
|
|
WHERE date_utc < 788918400 OR date_utc >= 1830297600;
|