SUMMARY Running Maintenance --> Search for Images and Videos with incomplete dates, the resulting dialogue proposes changes which do not seem to be changes STEPS TO REPRODUCE 1. Click Maintenance --> Search for Images and Videos with incomplete dates 2. A window with title "Search for images and Videos with MISSING dates" is opened 3. select "Search for images and videos with a valid date but an invalid timestamp" 4. Click Ok. OBSERVED RESULT The resulting dialogue says: <media file name> existing = Sun Dec 18 11:21:06 2022 new..... = Sun Dec 18 11:21:06 2022 <media file name> existing = Tue Aug 8 13:55:07 2023 new..... = Tue Aug 8 13:55:07 2023 <media file name> existing = Tue Aug 8 13:55:08 2023 new..... = Tue Aug 8 13:55:08 2023 <media file name> existing = Tue Aug 8 13:55:09 2023 new..... = Tue Aug 8 13:55:09 2023 <media file name> existing = Tue Aug 8 13:55:09 2023 new..... = Tue Aug 8 13:55:09 2023 <media file name> existing = Tue Aug 8 13:55:09 2023 new..... = Tue Aug 8 13:55:09 2023 etc.. EXPECTED RESULT The new date time to be different from the existing date time. SOFTWARE/OS VERSIONS MESA-INTEL: warning: Haswell Vulkan support is incomplete Operating System: EndeavourOS KDE Plasma Version: 6.3.5 KDE Frameworks Version: 6.14.0 Qt Version: 6.9.0 Kernel Version: 6.12.30-1-lts (64-bit) Graphics Platform: Wayland Processors: 4 × Intel® Core™ i5-4570R CPU @ 2.70GHz Memory: 7.7 GiB of RAM Graphics Processor: Intel® Iris® Pro Graphics 5200 ADDITIONAL INFORMATION running fresh git version
I reproduced this on both git master and my distribution-installed version 5.12.0. Willem, are the images all lacking a date/time in the file header, and do you have the "Trust image dates" option enabled? This is easy to reproduce with this image from the demo (which lacks a date/time in the EXIF header): $ exif demo/spiff.jpg | grep -i Date $ mkdir 505023 $ cp demo/spiff.jpg 505023/ # This test only works if the file has a non-zero fraction of a second in the modification time: $ stat 505023/spiff.jpg | awk '/Modify/ { print $2, $3 }' 2025-09-14 10:09:10.159101596 $ kphotoalbum --db 505023/ # create the new database # Select "Maintenance/Display images and videos with incomplete dates..." # Select "Search for images and videos with a valid date but an invalid time stamp" # Click OK - kphotoalbum doesn't find any images because the in-memory timestamp matches the files modification timestamp # Close the dialog, save the database, and exit kphotoalbum # The file date was read from the file's modification time but does not include the fractional seconds: $ awk '/startDate/ { print $3 }' 505023/index.xml startDate="2025-09-14T10:09:10" $ kphotoalbum --db 505023/ # reopen the database # Repeat the steps - kphotoalbum reports (for my copy of the image): spiff.jpg: existing = Sun Sep 14 10:09:10 2025 new..... = Sun Sep 14 10:09:10 2025 The difference is the fraction of the second read from the file's modification time which is not displayed to the user.
Fixed by https://invent.kde.org/graphics/kphotoalbum/-/merge_requests/43
(In reply to Randall Rude from comment #1) > I reproduced this on both git master and my distribution-installed version > 5.12.0. > > Willem, are the images all lacking a date/time in the file header, and do > you have the "Trust image dates" option enabled? > > This is easy to reproduce with this image from the demo (which lacks a > date/time in the EXIF header): > $ exif demo/spiff.jpg | grep -i Date > $ mkdir 505023 > $ cp demo/spiff.jpg 505023/ > # This test only works if the file has a non-zero fraction of a second in > the modification time: > $ stat 505023/spiff.jpg | awk '/Modify/ { print $2, $3 }' > 2025-09-14 10:09:10.159101596 > $ kphotoalbum --db 505023/ # create the new database > # Select "Maintenance/Display images and videos with incomplete dates..." > # Select "Search for images and videos with a valid date but an invalid time > stamp" > # Click OK - kphotoalbum doesn't find any images because the in-memory > timestamp matches the files modification timestamp > # Close the dialog, save the database, and exit kphotoalbum > # The file date was read from the file's modification time but does not > include the fractional seconds: > $ awk '/startDate/ { print $3 }' 505023/index.xml > startDate="2025-09-14T10:09:10" > $ kphotoalbum --db 505023/ # reopen the database > # Repeat the steps - kphotoalbum reports (for my copy of the image): > spiff.jpg: > existing = Sun Sep 14 10:09:10 2025 > new..... = Sun Sep 14 10:09:10 2025 > > The difference is the fraction of the second read from the file's > modification time which is not displayed to the user. I'm sorry but I can't recreate the situation I reported: I've started using digikam, and have removed KPA. So sorry about that; would have liked to have been able to confirm.