When "Use XMP sidecar for reading" is enabled, digiKam resolves "EXIF: original" to an older creation-date timeline instead of the actual original-date field. I can reproduce this with a JPEG + XMP sidecar pair where: - JPEG Exif.Photo.DateTimeOriginal = 2026:04:17 09:54:08 - XMP sidecar Xmp.exif.DateTimeOriginal = 2026-04-17T09:54:08 - XMP sidecar Xmp.xmp.CreateDate = 2023-08-31T14:46:16 - XMP sidecar Xmp.photoshop.DateCreated = 2023-08-31T14:46:16 With that setup, digiKam still shows the old 2023 date in Time Adjust when "Timestamp Used" is set to "EXIF: original". Steps to reproduce: 1. Open Item > Adjust Time & Date. 2. In "Timestamp Used", select "EXIF: original". Observed result: The preview/"Timestamp Used" value is the old date (from the XMP creation-date family), not the new original-date value. Expected result: "EXIF: original" should resolve to Exif.Photo.DateTimeOriginal. When sidecar reading is enabled, the equivalent XMP field should be Xmp.exif.DateTimeOriginal. It should not silently fall back to Xmp.xmp.CreateDate / Xmp.photoshop.DateCreated. I also tried to make this clear by calling digiKam's DMetadata API directly. For the same file pair, with sidecar reading enabled, DMetadata returns: - Exif.Photo.DateTimeOriginal = 2023:08:31 14:46:16 - Xmp.exif.DateTimeOriginal = 2026:04:17 09:54:08 - Xmp.xmp.CreateDate = 2023-08-31T14:46:16 - itemDateTime = 2023-08-31T14:46:16Z With sidecar reading disabled, DMetadata returns: - Exif.Photo.DateTimeOriginal = 2026:04:17 09:54:08 Software/OS versions: - digiKam 9.0.0 - exiv2 0.28.8 - ExifTool 13.50 - Qt 6.11.0 - Arch Linux rolling
In principle, the behavior is correct. When reading sidecar metadata, XMP metadata must override the Exif/IPTC metadata; otherwise, it cannot be modified. Furthermore, Exiv2 includes this conversion table: https://exiv2.org/conversion.html You can see how your date is generated as a result. However, we can temporarily disable the reading of sidecar metadata in the Time Adjust Tool, since the user explicitly requests Exif:original. This also means that if Exif:original is not present, we will get an invalid date, i.e., for images without metadata whose data is only present in XMP sidecar metadata. Maik
Git commit 2d386966e921b2edbfb0173fa6ea6e9fe09a7eec by Maik Qualmann. Committed on 08/04/2026 at 19:13. Pushed by mqualmann into branch 'master'. read Exif/IPTC date metadata without sidecar in the Time Adjust Tool FIXED-IN: 9.1.0 M +1 -1 NEWS M +22 -17 core/dplugins/bqm/metadata/timeadjust/timeadjust.cpp M +10 -6 core/dplugins/generic/metadata/timeadjust/timeadjustthread.cpp https://invent.kde.org/graphics/digikam/-/commit/2d386966e921b2edbfb0173fa6ea6e9fe09a7eec
(In reply to Maik Qualmann from comment #1) > In principle, the behavior is correct. When reading sidecar metadata, XMP > metadata must override the Exif/IPTC metadata; otherwise, it cannot be > modified. Furthermore, Exiv2 includes this conversion table: > https://exiv2.org/conversion.html > > You can see how your date is generated as a result. However, we can > temporarily disable the reading of sidecar metadata in the Time Adjust Tool, > since the user explicitly requests Exif:original. This also means that if > Exif:original is not present, we will get an invalid date, i.e., for images > without metadata whose data is only present in XMP sidecar metadata. > > Maik Thank you Maik, for referring the conversion table. I guess what I am seeing here is an edge case caused by incomplete editing. Thanks again for the fix.