<?xml version="1.0" encoding="UTF-8" standalone="yes" ?>
<!DOCTYPE bugzilla SYSTEM "https://bugs.kde.org/page.cgi?id=bugzilla.dtd">

<bugzilla version="5.0.6"
          urlbase="https://bugs.kde.org/"
          
          maintainer="sysadmin@kde.org"
>

    <bug>
          <bug_id>505023</bug_id>
          
          <creation_ts>2025-05-30 17:13:02 +0000</creation_ts>
          <short_desc>Proposed date changes no changes</short_desc>
          <delta_ts>2025-10-05 20:28:39 +0000</delta_ts>
          <reporter_accessible>1</reporter_accessible>
          <cclist_accessible>1</cclist_accessible>
          <classification_id>2</classification_id>
          <classification>Applications</classification>
          <product>kphotoalbum</product>
          <component>Backend</component>
          <version>GIT master</version>
          <rep_platform>Arch Linux</rep_platform>
          <op_sys>Linux</op_sys>
          <bug_status>RESOLVED</bug_status>
          <resolution>FIXED</resolution>
          
          
          <bug_file_loc></bug_file_loc>
          <status_whiteboard></status_whiteboard>
          <keywords></keywords>
          <priority>NOR</priority>
          <bug_severity>normal</bug_severity>
          <target_milestone>---</target_milestone>
          
          
          <everconfirmed>1</everconfirmed>
          <reporter name="willem">whobers</reporter>
          <assigned_to name="KPhotoAlbum Bugs">kphotoalbum-bugs-null</assigned_to>
          <cc>johannes</cc>
    
    <cc>rsquared42</cc>
          
          <cf_commitlink>d4318d39</cf_commitlink>
          <cf_versionfixedin>6.1.0</cf_versionfixedin>
          <cf_sentryurl></cf_sentryurl>
          <votes>0</votes>

      

      

      

          <comment_sort_order>oldest_to_newest</comment_sort_order>  
          <long_desc isprivate="0" >
    <commentid>2429152</commentid>
    <comment_count>0</comment_count>
    <who name="willem">whobers</who>
    <bug_when>2025-05-30 17:13:02 +0000</bug_when>
    <thetext>SUMMARY
Running Maintenance --&gt; 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 --&gt; Search for Images and Videos with incomplete dates 
2. A window with title &quot;Search for images and Videos with MISSING dates&quot; is opened
3. select &quot;Search for images and videos with a valid date but an invalid timestamp&quot;
4. Click Ok.

OBSERVED RESULT
The resulting dialogue says:

&lt;media file name&gt;
existing = Sun Dec 18 11:21:06 2022
new..... = Sun Dec 18 11:21:06 2022

&lt;media file name&gt;
existing = Tue Aug 8 13:55:07 2023
new..... = Tue Aug 8 13:55:07 2023

&lt;media file name&gt;
existing = Tue Aug 8 13:55:08 2023
new..... = Tue Aug 8 13:55:08 2023

&lt;media file name&gt;
existing = Tue Aug 8 13:55:09 2023
new..... = Tue Aug 8 13:55:09 2023


&lt;media file name&gt;
existing = Tue Aug 8 13:55:09 2023
new..... = Tue Aug 8 13:55:09 2023


&lt;media file name&gt;
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</thetext>
  </long_desc><long_desc isprivate="0" >
    <commentid>2454352</commentid>
    <comment_count>1</comment_count>
    <who name="Randall Rude">rsquared42</who>
    <bug_when>2025-09-14 16:35:26 +0000</bug_when>
    <thetext>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 &quot;Trust image dates&quot; 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 &apos;/Modify/ { print $2, $3 }&apos;
2025-09-14 10:09:10.159101596
$ kphotoalbum --db 505023/ # create the new database
# Select &quot;Maintenance/Display images and videos with incomplete dates...&quot;
# Select &quot;Search for images and videos with a valid date but an invalid time stamp&quot;
# Click OK - kphotoalbum doesn&apos;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&apos;s modification time but does not include the fractional seconds:
$ awk &apos;/startDate/ { print $3 }&apos; 505023/index.xml 
startDate=&quot;2025-09-14T10:09:10&quot;
$ 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&apos;s modification time which is not displayed to the user.</thetext>
  </long_desc><long_desc isprivate="0" >
    <commentid>2454355</commentid>
    <comment_count>2</comment_count>
    <who name="Johannes Zarl-Zierl">johannes</who>
    <bug_when>2025-09-14 17:40:57 +0000</bug_when>
    <thetext>Fixed by https://invent.kde.org/graphics/kphotoalbum/-/merge_requests/43</thetext>
  </long_desc><long_desc isprivate="0" >
    <commentid>2454595</commentid>
    <comment_count>3</comment_count>
    <who name="willem">whobers</who>
    <bug_when>2025-09-16 09:41:29 +0000</bug_when>
    <thetext>(In reply to Randall Rude from comment #1)
&gt; I reproduced this on both git master and my distribution-installed version
&gt; 5.12.0.
&gt; 
&gt; Willem, are the images all lacking a date/time in the file header, and do
&gt; you have the &quot;Trust image dates&quot; option enabled?
&gt; 
&gt; This is easy to reproduce with this image from the demo (which lacks a
&gt; date/time in the EXIF header):
&gt; $ exif demo/spiff.jpg | grep -i Date
&gt; $ mkdir 505023
&gt; $ cp demo/spiff.jpg 505023/
&gt; # This test only works if the file has a non-zero fraction of a second in
&gt; the modification time:
&gt; $ stat 505023/spiff.jpg | awk &apos;/Modify/ { print $2, $3 }&apos;
&gt; 2025-09-14 10:09:10.159101596
&gt; $ kphotoalbum --db 505023/ # create the new database
&gt; # Select &quot;Maintenance/Display images and videos with incomplete dates...&quot;
&gt; # Select &quot;Search for images and videos with a valid date but an invalid time
&gt; stamp&quot;
&gt; # Click OK - kphotoalbum doesn&apos;t find any images because the in-memory
&gt; timestamp matches the files modification timestamp
&gt; # Close the dialog, save the database, and exit kphotoalbum
&gt; # The file date was read from the file&apos;s modification time but does not
&gt; include the fractional seconds:
&gt; $ awk &apos;/startDate/ { print $3 }&apos; 505023/index.xml 
&gt; startDate=&quot;2025-09-14T10:09:10&quot;
&gt; $ kphotoalbum --db 505023/ # reopen the database
&gt; # Repeat the steps - kphotoalbum reports (for my copy of the image):
&gt; spiff.jpg:
&gt; existing = Sun Sep 14 10:09:10 2025
&gt; new..... = Sun Sep 14 10:09:10 2025
&gt; 
&gt; The difference is the fraction of the second read from the file&apos;s
&gt; modification time which is not displayed to the user.

I&apos;m sorry but I can&apos;t recreate the situation I reported: I&apos;ve started using digikam, and have removed KPA.
So sorry about that; would have liked to have been able to confirm.</thetext>
  </long_desc>
      
      

    </bug>

</bugzilla>