(this request is related to the comment 21 of the bug 484719) 1. Request In the Adjust Time & Date tool, allow the user to specify optionally a time zone (tz). If set, Digikam will create the tag QuickTime:CreationDate with the value of QuickTime:CreateDate and tz as time zone for each items of the selection. If exist, QuickTime:CreationDate-tz will override QuickTime:CreateDate for renaming based on a exif date pattern and for sorting by date. NB. It is not possible (at least with exiftool) to add a time zone to Quicktime:CreateDate, Quicktime:ModifyDate, and any date/time tag that is listed as an "integer" on the Quicktime tags page (https://exiftool.org/TagNames/QuickTime.html). On the other side, it seems QuickTime:CreationDate is used in the Apple world to store the local date of a video. Please see also https://exiftool.org/forum/index.php?topic=16289.0. 2. Why The actual behavior works when the video is taken in the same time zone that the PC running Digikam. Since it is the most usual use case, it is a nice "shortcut" (with a difficulty though : the need to identify if a video is UTC or local time according to the device type). But this shortcut is wrong for another use case, the one where the video was taken in another time zone that the pc running Digikam (typically during a travel to a foreign country). In this case, the photos and the videos are not sorted in chronological order (neither by date nor by name if renaming is based on an exif date pattern). 3. Miscellaneous The current behavior would not be broken : Digikam would continue to apply the time zone of the PC at import. it would be up to the user to select later the UTC videos to which he wants to create a local date by applying a time zone.
An alternative could be to offer this possibility only within the Queue Manager instead of the UI of Adjust Time & Date.
To say the truth, as for me, I don't need really a way to write QuickTime:CreationDate-tz on the related videos, it is easy to do outside of Digikam. What I need would be that Digikam uses QuickTime:CreationDate-tz as field - if it exist - to sort by date and to rename by date-pattern.
Git commit 31cabb77209609f304236a876fa760ce98ae2e70 by Maik Qualmann. Committed on 31/08/2024 at 20:28. Pushed by mqualmann into branch 'master'. enable writing of local time zone for video files M +13 -4 core/libs/metadataengine/exiftool/exiftoolparser_command.cpp https://invent.kde.org/graphics/digikam/-/commit/31cabb77209609f304236a876fa760ce98ae2e70
Selecting a video, Adjust Time & Date, don't touch anything except Ok buttom. After a few seconds, Digikam (with the last debug appimage) crashes (segmentation fault), please see the attached log. Unfortunately I can't use the debug mode because I get the following error when I add the debug option . Starting digiKam into GDB... Use 'bt' command on debugger prompt to get a crash backtrace. Use 'q' command to quit debugger session. gdb: /tmp/.mount_digiKay3vZe0/usr/lib/libssl.so.3: version `OPENSSL_3.2.0' not found (required by /usr/lib/libcurl.so.4) gdb: /tmp/.mount_digiKay3vZe0/usr/lib/libssl.so.3: version `OPENSSL_3.3.0' not found (required by /usr/lib/libcurl.so.4)
Created attachment 173205 [details] segfault log
Hmm, I can't reproduce it at the moment with my native digiKam version, AppImage test follows... Maik
I can reproduce it with the AppImage, it crashes in a Qt function, in QCalendar. The attempt to use QDateTime::toString() with a time zone placeholder fails. I suspect problems with the QLocale support in the AppImage, I will disable it for now. Maik
Git commit 7651bd9f0f26d33bede1764b3c9e620b0f21f73c by Maik Qualmann. Committed on 01/09/2024 at 18:38. Pushed by mqualmann into branch 'master'. prevent crash in AppImage with timezone string M +5 -6 core/libs/metadataengine/exiftool/exiftoolparser_command.cpp https://invent.kde.org/graphics/digikam/-/commit/7651bd9f0f26d33bede1764b3c9e620b0f21f73c
Crash fixed, thanks. Coming back to the request to see what happen now with video times : I have a pixel 5 video where exiftool -Time:all => "2024:05:02 02:29:59" for all date fields of the file (it is the right UTC time of the video). I added it to Digikam and I checked the ImageInformation table into the SQLite db : creationDate : 2024-05-02T04:29:59.000 digitizationDate : 2024-05-02T04:29:59.000 (Digikam applied the time zone of my computer, UTC+2) Than I want to 'Adjust Time & Date' of the video to the local time in order : 1) that it is sorted correctly compared to the photos when "View/Sort items/by creation date" 2) it can be renamed with a date pattern based on the local time in order to be sorted correctly with the photos when "View/Sort items/by Name". The video has been taken in South Korea, UTC+9. So I must adjust by +7 hours (-2+9). Checking the db after the adjust : creationDate : 2024-05-02T11:29:59.000 digitizationDate : 2024-05-02T04:29:59.000 Now I try to sort items by Creation date : ok ; by Name : ok. Nice ! But exiftool -Time:all => "2024:05:02 09:29:59" for the date fields of the file. That is logical but annoying since QuickTime:CreateDate is supposed to be UTC time. What will happen if we import later these "adjusted" videos into a new Digikam collection ? I think that this solution can lead to a lot of confusion for the user. That is why, as suggested in https://exiftool.org/forum/index.php?topic=16289.0 topic, I proposed that "Adjust Time & date" writes the adjusted time into the field QuickTime:CreationDate which supports an offset (in my example, the value to write would be 2024-05-02 02:29:59+09:00) and to store it into db.creationDate (for sorting and renaming purposes). Additionally, Digikam would use QuickTime:CreationDate, if it exists, instead of QuickTime:CreationDate when reading metadatas from file. To be sure that is possible, I tried : exiftool -QuickTime:CreationDate="2024:05:02 02:29:59+09:00" myfile.mp4 I get: "QuickTime": { "CreateDate": "2024:05:02 09:29:59", "ModifyDate": "2024:05:02 09:29:59" }, "Keys": { "CreationDate": "2024:05:02 02:29:59+09:00" }, According to my understanding of the topic linked above, it seems Apple uses this solution so solve the problem.
I forgot the case where the user want to correct the UTC time itself because he knows that the device set it incorrectly. Personally I don't care of this use case if this ever happens since I can correct it directly with exiftool. But from a Digikam point of view, may be it could give the choice with an option such as "force UTC time update ?" unset by default.
Request: to be able to have a coherent sorting between local time items and UTC time items (such as quicktime videos), whether sorting by date or sorting by name. The current implementation fails to achieve this request because it does not respect an essential constraint : don't lose the information of the original UTC time into the file ; otherwise if these video files are re-imported someday, Digikam will add the tz of the PC again (not to mention that the user will no longer be able to tell later if the video was already put in local time or not). Indeed, when the user "Adjust Time" to achieve a local time (applying an offset = tz of the location where the video has bee taken - tz of the pc at the import date), Digikam writes the new value to ALL date time fields of the file, thus losing UTC time value. ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ PS. The only case where the original UTC time itself could be modified in the file is if the user is aware that is a wrong UTC time. I don't know if it is possible though (may be a smartphone connected to a border network which has not the same time zone that the current location of the user ?). As far as I'm concerned, I don't need Digikam to take this case into account (if it ever exists, it is easy to take it in account with Exiftool before to import the relevant videos).
I found this (long) post on https://discussions.apple.com/docs/DOC-250002750 explaining how to fix incorrect sorting of movies and images. There is in particular the following passage : 3. Date in 'Keys:CreationDate' or 'UserData:DateTimeOriginal' sets the time and time zone, and it overrides all other time and time zone tags above. Keys overrides UserData if both exist (Photos ignores this UserData tag in .mov). iOS (8.4)-9 and newer inserts 'Keys:CreationDate' to its movies. So Keys:CreationDate, if it exists, is the reference date used by the Apple for sorting (which seems logical since this field normally has a time zone). Unless we find a better solution it would seem logical to do the same in Digikam, that is to say to do db.CreationDate = Keys:CreationDate (if it exists) when importing or reading metatadata from file. And to write "adjusted time" to Keys:CreationDate, keeping the UTC time unchanged.