Created attachment 65206 [details] "DownloadHistory" table of digikam table Version: 2.2.0 (using KDE 4.7.2) OS: Linux While importing new pictures from an SD card, digikam normally recognizes the pictures that has already been imported so that it's easy to import only the new ones. However, after the daylight savings time (30th of October 2011 this year), digikam fails to recognize pictures already imported if they were taken before 30th of October ! I.e. : digikam considers these pictures are new (not imported yet). Reproducible: Always Steps to Reproduce: 1) take a picture before daylight saving time 2) import that picture before daylight saving time with digikam 3a) import that picture again before daylight saving time with digikam => OK, digikam shows that the picture has already been imported 3b) import that picture again AFTER daylight saving time with digikam => NOT OK, digikam doesn't show that the picture has already been imported Expected Results: Daylight saving time should not affect this ! The picture attached shows why this happens. It is a view of the "DownloadHistory" table of the digikam database. First highlighted item shows the first time the picture "IMG_1736" was imported (in September) => the "filedate" field shows "20:33". Second highlighted item shows when I imported this same picture yesterday (i.e. after daylight saving time) => the "filedate" field shows "21:33". Conclusion: depending when you import a picture (after or before daylight saving time), the time ("filedate" field) is not the same => this bug happens.
This problem may be a bit out of our scope. I assume this is the story: Modern filesystems store the time stamp in UTC, while vfat stores it in local time. When accessing vfat, Linux will convert the time to UTC, and there is a one hour difference after DST change. I'm not quite sure about the Exif timestamps, I guess they'll be in camera local time.
(In reply to comment #1) > This problem may be a bit out of our scope. I don't really agree with you: the fact is that the majority of memory cards are vfat formatted (I think) => this must be taken into account. There are several ways to avoid this problem: store the EXIF time instead (this will avoid the problem because if you look the EXIF time of a photo after or before the DST change, it will remain the same, which is not the case of the file's time in VFAT). Another solution (less clean) is to consider that a file has already been downloaded if the 'filedate' field of the 'DownloadHistory' table is the same or with 1 hour difference.
Reading the Exif date is not an option because retrieving the metadata of all pictures on the memory card would be very slow. The one-hour-off solution does seem pretty dirty to me. With "out of our scope" I mean that this seems to be a shortcoming of the decades-old FAT. If this is indeed the case, and this is indeed applicable to all memory cards, I would be open to an algorithm which a) confirms that the memory card is vfat b) finds out the time of the DST in current time zone c) computes the DST-corrected date of the given pictures.
Additional info: Windows deals with DST in FAT file system but Linux doesn't and there is no intention of changing that -> see https://bugzilla.kernel.org/show_bug.cgi?id=68131 I'm surprised: am I the only one to be affected by this bug ? I think all the cameras use vfat memory card and so every one that use 'import picture' in digikam encounter this problem one day or another ?
No Nicofo you are not the only one affected by it, it's reproducible and I am working on fixing it right now.
(In reply to comment #5) > No Nicofo you are not the only one affected by it, it's reproducible and I > am working on fixing it right now. Great, thank you ! Next daylight saving time change will be on 29th of March, I'll be there to test it ;-)
Nicofo, Can you reproduce the dysfunction using last digiKam 4.2.0 ? Gilles Caulier
Hi Gilles, Yes, it is still reproducible with DK 4.4. (In reply to Islam Wazery from comment #5) > No Nicofo you are not the only one affected by it, it's reproducible and I am working on fixing it right now. @Islam, any news since your previous message ?
This file still valid using last digiKam 5.0.0 ? Gilles Caulier
Hi Gilles, I don't remember problem last DST (was still digikam 4.14) -> I think this bug can be closed. Thanks
Created attachment 102058 [details] Same picture undully imported twice Hi, I reopen this bug because, unlike I thought, it is actually not solved. Last DST was last weekend (30 Oct): all the pictures I made before (and that I had already imported) are not recognized anymore as already imported: if I import "New items" in Digikam, all my pictures imported before DST are re-imported again :( See picture attached (file digikam4.db), with the example of one picture taken before DST (25 Sept 18h35) but now recognized one hour later (25 Sept 19h35) so re-imported by digikam.
Hello, next daylight savings time is this weekend. You could take the opportunity to test and reproduce this bug ;-) 1) Take a picture today or tomorrow (with camera with SD card) and import it in DK 2) Next Sunday (25th of March) reimport pictures in DK -> previously imported pictures will not be recognized Thanks
Git commit 847c67fab4c88e0618c1d6e7c636a719c9fa19cd by Maik Qualmann. Committed on 24/03/2018 at 18:29. Pushed by mqualmann into branch 'master'. fix download history with check for one hour after and before the time FIXED-IN: 6.0.0 M +2 -1 NEWS M +13 -9 core/libs/database/coredb/coredbdownloadhistory.cpp https://commits.kde.org/digikam/847c67fab4c88e0618c1d6e7c636a719c9fa19cd
I think it's a good time to fix this bug a few hours before daylight saving time. ((:-)) The check of an hour before and after file date, I think, is the best and easiest solution. Maik
(In reply to Maik Qualmann from comment #14) > I think it's a good time to fix this bug a few hours before daylight saving > time. ((:-)) The check of an hour before and after file date, I think, is > the best and easiest solution. > > Maik Thank you very much, it works (tested with 6.0.0 beta). This closes my last annoying bug in digikam; making it nearly perfect now ;-)