Bug 331261 - Import not using Date/Time Original or create date EXIF data
Summary: Import not using Date/Time Original or create date EXIF data
Status: RESOLVED WORKSFORME
Alias: None
Product: digikam
Classification: Applications
Component: Import-PostProcessing (show other bugs)
Version: 4.13.0
Platform: Arch Linux Linux
: NOR major
Target Milestone: ---
Assignee: Digikam Developers
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2014-02-17 22:59 UTC by jay
Modified: 2017-08-16 05:55 UTC (History)
5 users (show)

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

Attachments
Add an attachment

Note You need to log in before you can comment on or make changes to this bug.
Description jay 2014-02-17 22:59:38 UTC 
When importing images using the 'Import->Add Images' function, the EXIF data for date isn't coming from the "Date/Time" or "Original
Create Date" EXIF data fields but rather appears to be originating from either the "File Modification Date/Time", "File Access Date/Time", and/or "File Inode Change Date/Time" EXIF fields.  This is a problem especially when using the "Date-based sub-albums" import setting, since the actual photo creation date and time is wrongly represented.

I also noticed that the thumbnails "Created:" field is also displaying the same wrong EXIF data.  Again, it's displaying modified date/time instead of original date/time.

Reproducible: Always

Steps to Reproduce:
1.  Import images with modified date/time differing from Original date/time using "Date-based sub-albums" import setting.
2.  
3.  
Actual Results:  
Newly imported images in sub-folder in "My Albums" shows modified instead of created date as folder name.

Expected Results:  
Folder should be using original image dates (instead of modified dates)
Comment 1 jay 2014-02-17 23:03:07 UTC 
FYI, the correct creation date is shown once the image is imported.  The folder that it's imported into is of course still not correct.
Comment 2 caulier.gilles 2014-09-01 07:51:10 UTC 
Jay,

This problem still here using last digiKam 4.2.0 ?

Gilles Caulier
Comment 3 Teemu Rytilahti 2014-11-17 01:17:52 UTC 
IIRC this is at the moment hard-coded to be the mtime of the file.
Comment 4 caulier.gilles 2015-01-20 14:58:35 UTC 
*** Bug 343053 has been marked as a duplicate of this bug. ***
Comment 5 Nicofo 2015-01-21 17:50:07 UTC 
@jay@nixpunk.com
To solve your problem, it is required that exif is read during import. I don't think it is possible: see bug #285683 comment 3 : "Reading the Exif date is not an option because retrieving the metadata of all pictures on the memory card would be very slow."

@Gilles Caulier
you put Bug #343053 as a duplicate of this one. It is more of less related but is something different:
- Here: the date taken at import (that will be used in Date-based sub-albums functionality) is the one of the file instead of the one of EXIF.
- Bug #343053 : the date at import (that will be used to set the file's date) is dependent of the setting 'Update file timestamp when files are modified' while it should not.
Comment 6 caulier.gilles 2015-08-13 08:02:22 UTC 
digiKam 4.12.0 is out.

https://www.digikam.org/node/741

Problem still reproducible ?

Gilles Caulier
Comment 7 kai.blauberg 2015-11-01 09:20:10 UTC 
The bug prevails still in digikam 4.13.0.

Kai
Comment 8 Maik Qualmann 2016-03-07 21:54:31 UTC 
If the option "Use file metadata (makes connection slower)" in the camera setup is enabled, then the EXIF date / time is used from the image. I think, we can close this bug.

Maik