Gwenview Importer only uses date/time from the filesystem metadata when renaming imported photos.
Not the EXIF information that holds the correct date/time that the picture has been taken.
After looking into the code, I found out that the datetime is determined by calling the function 'TimeUtils::dateTimeForFileItem'.
Consequently, the function 'TimeUtils::dateTimeForFileItem' is calling the function 'updateFromExif()' which in turn calls the function 'Exiv2ImageLoader::load' that returns 'false'. Then it falls back at reading the datetime from the filesystem metadata.
After printing out the error messages that cause the function 'Exiv2ImageLoader::load' to return 'false', I found that the Exiv2 error message is 'Failed to read image data' (doesn't help much). However, after I started playing with the size of the 'QByteArray header' (at the line where the file is read) that is passed as an argument to the 'Exiv2ImageLoader::load' function, I observed different errors until I managed to read the exif info from the file properly.
Some example sizes and different reported errors by Exiv2:
65536: Failed to read image data
66000: JPEG format error, rc = 5
131072 It reads fine. No error.
Didn't check numbers between 66000 and 131072 in order to find the exact threshold where I don't get a problem/error reading the exif information, but why should gwenview even bother about this number since exiv2 can do the job if we only provide the url (filepath) of the file to the Exiv2::ImageFactory::open() function? I guess exiv2 probably does the image reading in an even more efficient way according to the JPEG (or other) standard specifications (other than passing it a fixed number of bytes from an image as gwenview currently does).
So attached you can find a proposed patch that does exactly that: Adds a second instance of the function "Exiv2ImageLoader::load()" that acceps a "QString filePath" parameter and lets the Exiv2 library to handle the rest based on the given filePath.