147 prod rows (lib 1: 14, lib 2: 93, lib 4: 40) never get date_utc. They only have EXIF DateTime (exiftool IFD0:ModifyDate): marching-band scans, film scans, downloaded phone images.
The kamadak ingest path already takes DateTime as the capture date, which is where their legacy date_taken came from.
The exiftool resolver doesn't request ModifyDate, so backfill_utc_dates resolves these rows to fs_time and then refuses to replace a tag-sourced date with a filesystem time.
So they stay unresolved and get re-run through exiftool on every tick.
Fix
ModifyDate is added as the lowest-priority entry in EXIFTOOL_DATE_TAGS. Any capture tag still outranks it.
It's accepted only from IFD0. XMP and QuickTime ModifyDate are edit or mux times, so they're skipped.
An IFD0 reading is a camera wall clock and goes through the usual offset cascade (OffsetTime, then GPS, then the server zone).
Tests
ifd0_modify_date_is_a_last_resort: resolves with its offset, and a capture tag outranks it.
non_exif_modify_date_is_ignored: XMP and QuickTime ModifyDate are skipped.
Full suite and clippy are clean.
Checked by hand that exiftool reports IFD0:ModifyDate for two of the stuck prod files.
After deploy, the drain should take SELECT COUNT(*) FROM image_exif WHERE date_utc IS NULL down to about 0.
## Problem
147 prod rows (lib 1: 14, lib 2: 93, lib 4: 40) never get `date_utc`. They only have EXIF `DateTime` (exiftool `IFD0:ModifyDate`): marching-band scans, film scans, downloaded phone images.
- The kamadak ingest path already takes `DateTime` as the capture date, which is where their legacy `date_taken` came from.
- The exiftool resolver doesn't request `ModifyDate`, so `backfill_utc_dates` resolves these rows to `fs_time` and then refuses to replace a tag-sourced date with a filesystem time.
- So they stay unresolved and get re-run through exiftool on every tick.
## Fix
- `ModifyDate` is added as the lowest-priority entry in `EXIFTOOL_DATE_TAGS`. Any capture tag still outranks it.
- It's accepted only from `IFD0`. XMP and QuickTime `ModifyDate` are edit or mux times, so they're skipped.
- An IFD0 reading is a camera wall clock and goes through the usual offset cascade (OffsetTime, then GPS, then the server zone).
## Tests
- `ifd0_modify_date_is_a_last_resort`: resolves with its offset, and a capture tag outranks it.
- `non_exif_modify_date_is_ignored`: XMP and QuickTime `ModifyDate` are skipped.
- Full suite and clippy are clean.
- Checked by hand that exiftool reports `IFD0:ModifyDate` for two of the stuck prod files.
After deploy, the drain should take `SELECT COUNT(*) FROM image_exif WHERE date_utc IS NULL` down to about 0.
🤖 Generated with [Claude Code](https://claude.com/claude-code)
Scans, edited exports and some downloads carry only EXIF DateTime
(exiftool: IFD0:ModifyDate). The kamadak ingest path already takes it
as the capture date, but the exiftool resolver didn't ask for it, so
the date_utc drain resolved those rows to fs_time and then (rightly)
refused to overwrite their tag-sourced legacy date. 147 prod rows sat
on the legacy convention forever, re-running exiftool every tick.
ModifyDate is now the lowest-priority tag, and only from IFD0 — XMP /
QuickTime ModifyDate is an edit or mux time, not capture.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
cameron
merged commit a605ccd6f8 into master2026-10-17 04:10:57 +00:00
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.
Problem
147 prod rows (lib 1: 14, lib 2: 93, lib 4: 40) never get
date_utc. They only have EXIFDateTime(exiftoolIFD0:ModifyDate): marching-band scans, film scans, downloaded phone images.DateTimeas the capture date, which is where their legacydate_takencame from.ModifyDate, sobackfill_utc_datesresolves these rows tofs_timeand then refuses to replace a tag-sourced date with a filesystem time.Fix
ModifyDateis added as the lowest-priority entry inEXIFTOOL_DATE_TAGS. Any capture tag still outranks it.IFD0. XMP and QuickTimeModifyDateare edit or mux times, so they're skipped.Tests
ifd0_modify_date_is_a_last_resort: resolves with its offset, and a capture tag outranks it.non_exif_modify_date_is_ignored: XMP and QuickTimeModifyDateare skipped.IFD0:ModifyDatefor two of the stuck prod files.After deploy, the drain should take
SELECT COUNT(*) FROM image_exif WHERE date_utc IS NULLdown to about 0.🤖 Generated with Claude Code