https://bugs.kde.org/show_bug.cgi?id=505023
--- Comment #3 from willem <[email protected]> --- (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. -- You are receiving this mail because: You are watching all bug changes.
