"Date taken" corruption on metadata change, especially captions

Tue Apr 1 17:11:35 BST 2025

Hi, I wanted to close the loop here and say this problem did in fact
disappear for me once I could upgrade to 8.5x. I was hesitant to write back
till I could be sure, but I haven't had any issues since then and it's been
months, so that's great. Thanks
—
Charlie Gorichanaz

On Tue, Nov 12, 2024 at 9:02 PM Charlie Gorichanaz <charlie at gorichanaz.com>
wrote:

> Hello,
>
> I appreciate your attempt to replicate the issue. I just want to state
> here for the record I am still having this problem and have not been able
> to use Digikam to manage my photos since discovering the issue. (I am now
> on the further minor Arch Linux update to Digikam version 8.4.0-3.)
>
> I'm hoping someone else here has seen this problem and knows how I might
> resolve it.
>
> Thanks,
> Charlie Gorichanaz
>
>
> On Thu, Oct 24, 2024 at 11:31 AM Maik Qualmann <metzpinguin at gmail.com>
> wrote:
>
>> I cannot reproduce any problem with the sample image (tested with
>> digiKam-8.5.0), it is imported with a creation date of 2024:08:28
>> 18:57:15.
>> This corresponds to the Exif DateTimeOriginal metadata. The time offset
>> Exif
>> metadata of -07:00 hours is currently not respected by digiKam. We have a
>> bug
>> report on this as a request.
>> If I add a title or caption, this does not change the creation date. The
>> file
>> modification date changes or not, depending on the settings in digiKam.
>>
>> Maik
>>
>> Am Donnerstag, 24. Oktober 2024, 18:26:08 Mitteleuropäische Sommerzeit
>> schrieb
>> Charlie Gorichanaz:
>> > Sure,
>> >
>> > Attached is another image PXL_20240829_015715758.jpg from the same phone
>> > camera from the same album that I believe I have not touched at all. My
>> > filesystem says it was modified Wednesday, 28 August 2024 at 18:57 (in
>> my
>> > local UTC-7 zone), which seems to match the filename's UTC timestamp.
>> >
>> > I initially observed this file has the correct local timestamp in the
>> album:
>> > [image: screenshot_2024-10-24_092137.png]
>> > Upon adding a caption, it shifts 7 hours ahead:
>> > [image: screenshot_2024-10-24_092155.png]
>> > And upon modifying that caption, it shifts 7 hours ahead:
>> > [image: screenshot_2024-10-24_092215.png]
>> > Note the same thing happens when I use the "Title" field as when I used
>> the
>> > "Captions" field.
>> >
>> > Thanks,
>> > Charlie
>> >
>> > On Thu, Oct 24, 2024 at 3:37 AM Maik Qualmann <metzpinguin at gmail.com>
>> wrote:
>> > > Can you send me a sample image without them having added a caption
>> yet?
>> > >
>> > > Maik
>> > >
>> > > Am Donnerstag, 24. Oktober 2024, 09:00:57 Mitteleuropäische Sommerzeit
>> > > schrieb
>> > >
>> > > Charlie Gorichanaz:
>> > > > Thank you for the response Maik.
>> > > >
>> > > > I verified selecting that photo, selecting Item > Reread Metadata
>> from
>> > >
>> > > File
>> > >
>> > > > does fix the date (though it sets it to the UTC date, not my local
>> time,
>> > >
>> > > so
>> > >
>> > > > I'm not sure if that's right).  But then when I edit the caption
>> text
>> > > > again, the photo time displayed under the thumbnail advances by 7
>> hours.
>> > > > This happens repeatedly each time I edit the caption. Is that
>> expected
>> > > > based on the bug you're describing?
>> > > >
>> > > > At least I can reread the metadata apparently once I am done
>> editing all
>> > > > the captions, I think.
>> > > > —
>> > > > Charlie Gorichanaz
>> > > >
>> > > >
>> > > > On Wed, Oct 23, 2024 at 10:58 PM Maik Qualmann <
>> metzpinguin at gmail.com>
>> > > >
>> > > > wrote:
>> > > > > Unfortunately, there is a bug in digiKam-8.4.0 that means that the
>> > >
>> > > entries
>> > >
>> > > > > for
>> > > > > rating, creation date and digitization date are not read correctly
>> > > > > when
>> > > > > images
>> > > > > are imported for the first time.
>> > > > > So you have to read the metadata from the file again for all
>> images
>> > > > > imported
>> > > > > with digiKam-8.4.0. This corrects the first incorrect metadata
>> import.
>> > > > >
>> > > > > Maik
>> > > > >
>> > > > > Am Donnerstag, 24. Oktober 2024, 01:39:26 Mitteleuropäische
>> Sommerzeit
>> > > > > schrieb
>> > > > >
>> > > > > Charlie Gorichanaz:
>> > > > > > Hello,
>> > > > > >
>> > > > > > I've recently found Digikam seems to be corrupting the dates on
>> my
>> > > > >
>> > > > > photos.
>> > > > >
>> > > > > > I believe this happened after I ran an update from Arch Linux
>> > > > > > package
>> > > > > > digikam-8.4.0-1 to digikam-8.4.0-2, which was built September
>> 21 and
>> > > > >
>> > > > > which
>> > > > >
>> > > > > > I installed more recently than that.
>> > > > > >
>> > > > > > I am in Pacific time and my Linux computer is configured as
>> such, in
>> > > > >
>> > > > > UTC-7.
>> > > > >
>> > > > > > My photos are a combination of files from a Pixel phone (with
>> > >
>> > > filenames
>> > >
>> > > > > > using the UTC timestamp) and Nikon Z7ii. I haven't figured out
>> > >
>> > > exactly
>> > >
>> > > > > what
>> > > > >
>> > > > > > is happening, but I noticed the files jump around in my album
>> after
>> > > > > > I
>> > > > > > add
>> > > > > > flags or write captions. This can happen multiple times. It
>> seems
>> > >
>> > > like
>> > >
>> > > > > they
>> > > > >
>> > > > > > jump ahead by 7 or 14 hours upon such metadata changes. If I
>> edit a
>> > > > >
>> > > > > single
>> > > > >
>> > > > > > photo's caption multiple times, the file can end up several days
>> > >
>> > > after
>> > >
>> > > > > > where it should be in the album. This is driving me crazy, as I
>> am
>> > > > > > trying
>> > > > > > to sort photos chronologically for the purpose of writing
>> journals
>> > >
>> > > and
>> > >
>> > > > > > blogs.
>> > > > > >
>> > > > > > For example, here's a photo I edited the caption about 10 or 15
>> > >
>> > > times.
>> > >
>> > > > > You
>> > > > >
>> > > > > > can see the "camera created date" showing below the thumbnail is
>> > >
>> > > 09-05
>> > >
>> > > > > > 06:33 despite that it should be 08-29 20:33 local time or 08-30
>> > > > > > 03:33
>> > > > >
>> > > > > UTC.
>> > > > >
>> > > > > > I see now none of the metadata fields with "date" in the name
>> > >
>> > > actually
>> > >
>> > > > > have
>> > > > >
>> > > > > > that 09-05 date, so I'm not sure where it's coming from.
>> > > > > >
>> > > > > > [image: screenshot_2024-10-23_163148.png]
>> > > > > >
>> > > > > > Is anyone else experiencing something like this?
>> > > > > >
>> > > > > > Note I am unfortunately not 100% sure if this was working
>> correctly
>> > >
>> > > for
>> > >
>> > > > > me
>> > > > >
>> > > > > > on Arch 8.4.0-1. The fact that package exists on my local system
>> > >
>> > > makes
>> > >
>> > > > > > me
>> > > > > > think I was using 8.4.0 successfully before I installed the
>> 8.4.0-2
>> > > > >
>> > > > > package
>> > > > >
>> > > > > > recently, but the changes
>> > > > > > <
>> > >
>> > >
>> https://gitlab.archlinux.org/archlinux/packaging/packages/digikam/-/commit
>> > >
>> > > > > /
>> > > > >
>> > > > > > b9a9eee00bd55376cac33070d3632e93d61ad443> there seem so small I
>> am
>> > >
>> > > not
>> > >
>> > > > > sure
>> > > > >
>> > > > > > what the problem could be. So there's a chance I was using 8.3.0
>> > > > > > when
>> > > > >
>> > > > > this
>> > > > >
>> > > > > > was working.
>> > > > > >
>> > > > > > Thank you,
>> > > > > > Charlie Gorichanaz
>> > > > > >
>> > > > > > P.S. I will be on a short camping trip for the next few days,
>> so I
>> > >
>> > > may
>> > >
>> > > > > not
>> > > > >
>> > > > > > be able to reply promptly, but I will certainly be back! Thanks.
>>
>>
>>
>>
>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/digikam-users/attachments/20250401/008cf8d3/attachment.htm>