Bug 389814

Summary: Date-based Sub-albums uses modification date instead of metadata date
Product: [Applications] digikam Reporter: tuxflo <flo.hennig>
Component: Import-AlbumsAssignee: Digikam Developers <digikam-bugs-null>
Status: RESOLVED FIXED    
Severity: normal CC: caulier.gilles, metzpinguin
Priority: NOR    
Version: 5.8.0   
Target Milestone: ---   
Platform: Other   
OS: Linux   
Latest Commit: Version Fixed In: 8.0.0

Description tuxflo 2018-02-03 04:14:44 UTC
I facing a similar problem as https://bugs.kde.org/show_bug.cgi?id=301936 but instead of rename, I'm having problems with the "Date-based Sub-album" import.

Steps to reproduce:
1. Change the modification date of some images  to a different date as the "Creation date" stored in the metadata.

2. Open the Import dialog (Crtl+Alt+I), select the images and enter "yyyy/yyyy-MM/yyyy-MM-dd" as custom date in the "Auto-creation of Albums" settings.

3. Import the images.

Current result: Sub albums are created by the modification date entered in step 1.

Expected result: Sub albums are created by the creation date of the images (anything else doesn't make sense).

If possible let the user choose which date should be used as described in the linked bug ("Use file metadata (makes connection slower).")
Comment 1 Maik Qualmann 2018-02-03 21:19:19 UTC
If you use the option "Use file metadata (makes connection slower)" the creation date from the EXIF metadata is used. And the result is what you want. If this option is disabled, the file date will be used, that's all. This option exists to speed up the connection to card readers or GPhoto2 devices. If you always want the EXIF date, activate the option. There is an exception for RAW files and GPhoto2 devices. We can only solve this problem in the future by first temporarily downloading all the images and then applying any date or time modifications.

Maik
Comment 2 Maik Qualmann 2018-02-03 21:21:49 UTC

*** This bug has been marked as a duplicate of bug 331167 ***
Comment 3 caulier.gilles 2022-11-24 16:52:21 UTC
Fixed with #331167