While digging through date_time_extractor.py with Claude, we found something that looks like it mis-dates a lot of photos, but the fix involves a design trade-off, so I'd like your steer before opening a PR.
In DEFAULT_RULES_PARAMS, rule id 15 (EXIF:DateTime) comes before rule id 1 (EXIF:DateTimeOriginal), and the first matching rule wins. EXIF:DateTime is the modification timestamp: photo editors (Lightroom, Photoshop, GIMP, some phone gallery apps) set it to the time the file was saved. So with the default rules, any photo that was ever edited outside LibrePhotos shows up in the timeline at its edit date instead of its capture date. A vacation photo from 2019 that was cropped in 2024 lands in 2024.
The ordering was introduced in cc51074 ("Make timestamp editable"), and as far as we can tell it's intentional: when a user edits a timestamp in LibrePhotos with save_metadata_to_disk enabled, _save_metadata writes the new value to EXIF:DateTime (models/photo.py, tags_to_write[Tags.DATE_TIME] = self.timestamp), and rule 15 at the top makes that edit win on re-import. So EXIF:DateTime is doing double duty as the persistence vehicle for user edits, and that's exactly what makes externally edited photos mis-date.
One observation that may make this easier: user-edited timestamps are already preserved by rule id 14 (USER_DEFINED, top of the list), which reads from the database. So the rule-15-first ordering only actually matters when the database is rebuilt from scratch and the only trace of the user's edit is the tag in the file. Demoting rule 15 below rule 1 would fix the edit-date problem for every externally edited photo on every scan, at the cost of losing in-app timestamp edits after a full DB wipe — and only for photos that also have a DateTimeOriginal tag (if they had one, the user probably wasn't fixing a missing date anyway).
Options we see, roughly in order of how much they change:
- Just demote rule 15 below rule 1 in the defaults. Smallest change; trade-off as described above.
- Demote rule 15 and change the write-back target so in-app edits survive a rebuild: write user edits to
EXIF:DateTimeOriginal (arguably the semantically correct tag for "when was this taken") or to an XMP sidecar tag that gets its own high-priority rule.
- Keep the ordering and treat this as working-as-intended, documenting that edited photos need a manual timestamp fix.
We'd lean toward option 2, but you know the history of user expectations here better. Existing installs keep their stored rules JSON either way, so any change would only affect new users/defaults unless migrated deliberately — also your call whether a migration is wanted.
(Analysis and writing by Claude, directed by me.)
While digging through
date_time_extractor.pywith Claude, we found something that looks like it mis-dates a lot of photos, but the fix involves a design trade-off, so I'd like your steer before opening a PR.In
DEFAULT_RULES_PARAMS, rule id 15 (EXIF:DateTime) comes before rule id 1 (EXIF:DateTimeOriginal), and the first matching rule wins.EXIF:DateTimeis the modification timestamp: photo editors (Lightroom, Photoshop, GIMP, some phone gallery apps) set it to the time the file was saved. So with the default rules, any photo that was ever edited outside LibrePhotos shows up in the timeline at its edit date instead of its capture date. A vacation photo from 2019 that was cropped in 2024 lands in 2024.The ordering was introduced in cc51074 ("Make timestamp editable"), and as far as we can tell it's intentional: when a user edits a timestamp in LibrePhotos with
save_metadata_to_diskenabled,_save_metadatawrites the new value toEXIF:DateTime(models/photo.py,tags_to_write[Tags.DATE_TIME] = self.timestamp), and rule 15 at the top makes that edit win on re-import. SoEXIF:DateTimeis doing double duty as the persistence vehicle for user edits, and that's exactly what makes externally edited photos mis-date.One observation that may make this easier: user-edited timestamps are already preserved by rule id 14 (
USER_DEFINED, top of the list), which reads from the database. So the rule-15-first ordering only actually matters when the database is rebuilt from scratch and the only trace of the user's edit is the tag in the file. Demoting rule 15 below rule 1 would fix the edit-date problem for every externally edited photo on every scan, at the cost of losing in-app timestamp edits after a full DB wipe — and only for photos that also have aDateTimeOriginaltag (if they had one, the user probably wasn't fixing a missing date anyway).Options we see, roughly in order of how much they change:
EXIF:DateTimeOriginal(arguably the semantically correct tag for "when was this taken") or to an XMP sidecar tag that gets its own high-priority rule.We'd lean toward option 2, but you know the history of user expectations here better. Existing installs keep their stored
rulesJSON either way, so any change would only affect new users/defaults unless migrated deliberately — also your call whether a migration is wanted.(Analysis and writing by Claude, directed by me.)