| Summary: | Proposed date changes no changes | ||
|---|---|---|---|
| Product: | [Applications] kphotoalbum | Reporter: | willem <whobers> |
| Component: | Backend | Assignee: | KPhotoAlbum Bugs <kphotoalbum-bugs-null> |
| Status: | RESOLVED FIXED | ||
| Severity: | normal | CC: | johannes, rsquared42 |
| Priority: | NOR | ||
| Version First Reported In: | GIT master | ||
| Target Milestone: | --- | ||
| Platform: | Arch Linux | ||
| OS: | Linux | ||
| Latest Commit: | d4318d39 | Version Fixed In: | 6.1.0 |
| Sentry Crash Report: | |||
|
Description
willem
2025-05-30 17:13:02 UTC
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.
(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. |