518687 2026-04-08 09:29:13 +0000 Time Adjust "EXIF: original" uses old XMP CreateDate/DateCreated instead of Xmp.exif.DateTimeOriginal 2026-04-09 02:57:47 +0000 1 1 2 Applications digikam Plugin-Generic-TimeAdjust 9.0.0 Arch Linux Linux RESOLVED FIXED NOR normal --- 0 wsyxbcl digikam-bugs-null caulier.gilles metzpinguin https://invent.kde.org/graphics/digikam/-/commit/2d386966e921b2edbfb0173fa6ea6e9fe09a7eec 9.1.0 0 oldest_to_newest 2508799 0 wsyxbcl 2026-04-08 09:29:13 +0000 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 2508812 1 metzpinguin 2026-04-08 10:38:15 +0000 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 2508977 2 metzpinguin 2026-04-08 19:14:14 +0000 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 2509006 3 wsyxbcl 2026-04-09 02:57:47 +0000 (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.