Cameron CordesandClaude Opus 5.5
36e4af9fa6
match_filename_date only gated the unix-timestamp branch to years 1995..=now+1; the five wall patterns returned any NaiveDateTime. Counters and IDs shaped like YYYYMMDD_HHMMSS (an app's VID_<counter>_<HHMMSS>, Facebook's <8 digits>_<id>_o.jpg) became dates of record in years from 267 to 9985: 67 rows on prod, all via screenshot_compact. Both branches now share plausible_filename_year; a wall miss falls through to the next pattern and then the rest of the waterfall. The filename audit no longer proposes these dates. A data migration clears the five date columns on filename-sourced rows dated outside [1995, 2028) UTC, so backfill_missing_date_taken re-resolves them from EXIF / exiftool / fs time on the next ticks. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
24 lines
1.0 KiB
SQL
24 lines
1.0 KiB
SQL
-- #160: the filename wall-clock patterns had no year gate, so counters and
|
|
-- IDs shaped like YYYYMMDD_HHMMSS (`VID_22290524_080551.mp4`, Facebook's
|
|
-- `10530519_101527…_o.jpg`) became dates of record in years like 1053 and
|
|
-- 2229. The matcher now rejects years outside 1995..=now+1; this clears
|
|
-- the rows it already dated so they're re-resolved by the fixed waterfall.
|
|
--
|
|
-- Both the legacy pair and the new-contract triple are cleared:
|
|
-- `date_taken IS NULL` puts the row back in `backfill_missing_date_taken`,
|
|
-- which rewrites all five columns (EXIF / exiftool / fs_time now that the
|
|
-- filename no longer matches). Only filename-sourced rows dated outside
|
|
-- [1995-01-01, 2028-01-01) UTC are touched; a real date re-resolves to
|
|
-- itself anyway.
|
|
UPDATE image_exif
|
|
SET date_taken = NULL,
|
|
date_taken_source = NULL,
|
|
date_utc = NULL,
|
|
camera_offset_minutes = NULL,
|
|
date_taken_tz_source = NULL
|
|
WHERE date_taken_source = 'filename'
|
|
AND (
|
|
date_taken < 788918400 OR date_taken >= 1830297600
|
|
OR date_utc < 788918400 OR date_utc >= 1830297600
|
|
);
|