Bug 386059 - Table view show incorrect dates if Exif PreviewDateTime is present (Exif Creation and Digitization dates are correct)
Summary: Table view show incorrect dates if Exif PreviewDateTime is present (Exif Crea...
Status: RESOLVED NOT A BUG
Alias: None
Product: digikam
Classification: Applications
Component: Albums-TableView (show other bugs)
Version: 5.8.0
Platform: Microsoft Windows Microsoft Windows
: NOR normal
Target Milestone: ---
Assignee: Digikam Developers
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2017-10-22 10:11 UTC by hardy.public
Modified: 2022-01-02 09:59 UTC (History)
2 users (show)

See Also:
Latest Commit:
Version Fixed In: 7.5.0
Sentry Crash Report:


Attachments
Table (57.10 KB, image/png)
2017-10-22 10:11 UTC, hardy.public
Details
ExampleOfProblem (36.51 KB, image/png)
2017-10-22 15:50 UTC, hardy.public
Details

Note You need to log in before you can comment on or make changes to this bug.
Description hardy.public 2017-10-22 10:11:34 UTC
Created attachment 108502 [details]
Table

If I have a scanned JPEG image with the following EXIF:

  DateTimeOriginal: 1919
  CreateDate: 1919

but...
  PreviewDateTime: 1930

The table sort order uses PreviewDateTime not DateTimeOriginal or CreateDate as would be expected. Since PreviewDateTime is not changeable in digiKam, the sort order is stuck in incorrect order.

The same problem occurs in Thumbnails: The sort order is by PreviewDateTime.
Comment 1 hardy.public 2017-10-22 12:44:01 UTC
Just to be clear, the EXIF editor shows the correct values. The table view does not.
Comment 2 Maik Qualmann 2017-10-22 13:34:29 UTC
DigiKam does not use Exif.Image.PreviewDateTime to get the date of a file. The entries "1919" would not be a valid date for Exif.Image.DateTime and Exif.Photo.DateTimeOriginal. DigiKam would therefore use the file date from the file system. Which date string is entered exactly? Possibly please provide a test image. Problem is not reproducible here.

Maik
Comment 3 hardy.public 2017-10-22 15:50:05 UTC
Sorry I did not write the exact string in the OP. I shortened it to 1916 but it was a valid format. "YYYY:MM:DD HH:MM:SS".

I attach another example screenshot. You can see why I concluded it is associated with PreviewDateTime.

Anyway this can be closed because I think I know what's happened now.

- I previously used Picasa which may have set DateTimeOriginal, CreateDate & PreviewDateTime to incorrect timestamp 1984:01:01 12:46:26.

- Then I imported the image into digiKam which then records 1984 etc. in its database as expected.

- Then I corrected the date to 1916 probably using digiKam for DateTimeOriginal and CreateDate but PreviewDateTime remains as 1984 because digiKam does not use it as you say. The metadata is written to the image but the digiKam database was not updated for some reason.

- When I create a copy of the problem image, the database entry is correct 1916. etc.

- If I Reread Metadata I get the correct 1916 date in the table view for the original image. I was mistakenly thinking that Refresh did this task.


In summary, the database must have gotten out-of-synch with the image metadata but rereading fixes the problem. Problem solved.
Comment 4 hardy.public 2017-10-22 15:50:35 UTC
Created attachment 108513 [details]
ExampleOfProblem