Bug 518687

Summary: Time Adjust "EXIF: original" uses old XMP CreateDate/DateCreated instead of Xmp.exif.DateTimeOriginal
Product: [Applications] digikam Reporter: wsyxbcl
Component: Plugin-Generic-TimeAdjustAssignee: Digikam Developers <digikam-bugs-null>
Status: RESOLVED FIXED    
Severity: normal CC: caulier.gilles, metzpinguin
Priority: NOR    
Version First Reported In: 9.0.0   
Target Milestone: ---   
Platform: Arch Linux   
OS: Linux   
Latest Commit: https://invent.kde.org/graphics/digikam/-/commit/2d386966e921b2edbfb0173fa6ea6e9fe09a7eec Version Fixed/Implemented In: 9.1.0
Sentry Crash Report:

Description wsyxbcl 2026-04-08 09:29:13 UTC 
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
Comment 1 Maik Qualmann 2026-04-08 10:38:15 UTC 
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
Comment 2 Maik Qualmann 2026-04-08 19:14:14 UTC 
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
Comment 3 wsyxbcl 2026-04-09 02:57:47 UTC 
(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.