Created attachment 168088 [details] metadata exif I have noticed some inconsistencies regarding the creation date lets take a raw that I have created on 2024-03-17 at 10:42 in the thumbnails view the created date is 2024-03-17 12h42 in the metadata view , the exiftool provide 2024-03-17 10:42 but the exif provide in the photograph Information a date and time 2024-03-17 13:42 (digitalized and original), while XMP provide 2024-03-17T12:42Z Attached the corresponding screenshot this behavior seems specific to some raw file, other in the same folder have a normal behavior except the Exif which is 1hour later than the real creation date As a consequence , using the sort by creation date is not consistent
Created attachment 168089 [details] metadata exiftool
Created attachment 168090 [details] metadata xmp
The "Z" at the end of the timestamp is already fixed for digiKam-8.4.0, but that doesn't explain the time difference. I suspect the creation date was incorrectly recorded in the database, please reread the metadata from the image. Report whether the problem is resolved. It still looks like you're using sidecar because ExifTool doesn't display XMP metadata. Maik
(In reply to Maik Qualmann from comment #3) > The "Z" at the end of the timestamp is already fixed for digiKam-8.4.0, but > that doesn't explain the time difference. I suspect the creation date was > incorrectly recorded in the database, please reread the metadata from the > image. Report whether the problem is resolved. > > It still looks like you're using sidecar because ExifTool doesn't display > XMP metadata. > > Maik just reread the metadata, but problem is worst , createion date is now 13:42 See attached
Created attachment 168095 [details] metadata after reread
I can reproduce the behavior here with a digiKam version before bug 484882. To fix the behavior with a corrected version, they need to write the correct timestamps into the sidecars again. Maik
(In reply to Maik Qualmann from comment #6) > I can reproduce the behavior here with a digiKam version before bug 484882. > To fix the behavior with a corrected version, they need to write the correct > timestamps into the sidecars again. > > Maik "they need to write the correct timestamps into the sidecars again." How to proceed ? find attached , screenshots of my settings regarding metadata
Created attachment 168098 [details] metadata sidecar settings
Created attachment 168099 [details] metadata behavior settings
Git commit 1acc73bfff6868f88b451e3a0c1833dd03354023 by Maik Qualmann. Committed on 03/04/2024 at 16:39. Pushed by mqualmann into branch 'master'. fix missing convert from caption timestamp to local time Related: bug 484957 FIXED-IN: 8.4.0 M +6 -2 core/libs/metadataengine/containers/captionvalues.cpp https://invent.kde.org/graphics/digikam/-/commit/1acc73bfff6868f88b451e3a0c1833dd03354023
To solve the problem with a corrected digiKam version, the following steps would also be conceivable. 1. Delete sidecar of the relevant raw files. 2. Disable all metadata write settings (to prevent deletion in the database) 3. Re-read metadata of the raw images. 4. Enable all metadata write settings. 5. Write metadata to the RAW images to create new sidecars. Maik
(In reply to Maik Qualmann from comment #11) > To solve the problem with a corrected digiKam version, the following steps > would also be conceivable. > > 1. Delete sidecar of the relevant raw files. > 2. Disable all metadata write settings (to prevent deletion in the database) > 3. Re-read metadata of the raw images. > 4. Enable all metadata write settings. > 5. Write metadata to the RAW images to create new sidecars. > > Maik done and time corrected thanks
Hi I see the problem is fixed in 8.4.0, just wondering what I will have to do to retreive the correct time. Will it be "automatic" or I will have to execute a process like the one shared by Maik Also for information, the time is changed when executing a "read metadata from file to database"