Created attachment 138328 [details] AdjustTimeDate calculation SUMMARY AdjustTimeDate changes the value of the LastModified field only during the calculation. In addition, the date of the attached files is very strange.07.07.2036 STEPS TO REPRODUCE 1. AdjustTimeDate arvutus (ATD scr) 2. During the calculation, the LastModified date is 01.06.1900 3. At the end of the calculation, the LastModified date is displayed 07.07.2036 OBSERVED RESULT The LastModified date does not change in the digiKam calculation. Other programs such as Exif Date Changer can change the LastModified date 01.06.1900. The digiKam calculation restores an invalid date 07.07.2036 EXPECTED RESULT The LastModified date can be changed in the program SOFTWARE/OS VERSIONS Windows: macOS: Linux/KDE Plasma: (available in About System) KDE Plasma Version: KDE Frameworks Version: Qt Version: ADDITIONAL INFORMATION
Created attachment 138329 [details] AdjustTimeDate calculation2
Can I email 2 problematic pictures? Hannes
The problem is clear, we use a 32-bit integer time stamp, this is enough around 1900. Since we are already using _wutime64 under Windows, the fix should not be a problem. I'm doing it tonight. Maik
The current limit is more precisely 01/01/1904. Maik
Git commit 047d78ab45b3edef87f5f843ac11b3d67355e6a4 by Maik Qualmann. Committed on 11/05/2021 at 18:40. Pushed by mqualmann into branch 'master'. try to fix file time under Windows M +1 -14 core/libs/threadimageio/engine/dfileoperations.cpp https://invent.kde.org/graphics/digikam/commit/047d78ab45b3edef87f5f843ac11b3d67355e6a4
Created attachment 138690 [details] Sample file whose Last modified date cannot be changed The date of the attached file Last modified cannot be changed. What could be the reason?
I guess you want to set the date to something around 1948. No problem here under Linux. We cannot currently set a date older than 12/13/1901 under Linux. Under Windows the limit is unfortunately 01/01/1970, no negative integer values are processed. We would have to use native Windows functions to be able to set an older date. If you want to search a little in Google for the cause, then use these keywords: Unix start date, Unix 2038 problem. I would not set old scanned documents to an old modification date. Technically speaking, the digital scans could not have been created at that time. Maik
Thank you for the explanation! Last modified date is more appropriate to leave the operating system managed. Is it possible to add an explanation of the reason to the error message that occurs. At the moment digiKam is like trying to change this date and the average user gets the impression that the program is not working or the file is corrupt. Hannes
Maik, If there is a note to add in the online documentation section of this tool about this problem, let's me here... https://docs.digikam.org/en/post_processing/time_adjust.html Gilles
Maik, Let's me hear the information to patch the online doc to close this report. Gilles
Git commit 124cb9e7184570769b40aedf1caa35dcecaa2411 by Maik Qualmann. Committed on 29/10/2023 at 15:23. Pushed by mqualmann into branch 'master'. use QIODevice to set the modification timestamp M +22 -92 core/libs/metadataengine/engine/metaengine_p.cpp M +35 -127 core/libs/threadimageio/engine/dfileoperations.cpp https://invent.kde.org/graphics/digikam/-/commit/124cb9e7184570769b40aedf1caa35dcecaa2411
Even with QIODevice the file date is limited to December 13, 1901. The test on Windows is still pending. Maik
By using the QT-File API, we can now set a modification date under Windows that limited is due to the calendar function of the Time Adjust Tool on September 14, 1752. Linux: December 13, 1901 Windows: September 14, 1752 Maik