[digikam] [Bug 462916] Different renaming behaviors for video files depending of the device
https://bugs.kde.org/show_bug.cgi?id=462916 --- Comment #19 from mahikeulbody --- (In reply to Maik Qualmann from comment #18) > The two samples from here have the correct date (time zone is respected since > Android was detected as a device). As I said, I confirm that 8.0 corrects this problem. Thanks. > If you have a sample that you think digiKam is reporting an incorrect date, > please provide it. My question did not imply a possible bug. But as you said "other users want it to be displayed in the correct local time as well" I took the opportunity to ask which local time you was talking about : the one where the photo/video was taken or the one on the computer where digikam is running ? So, in my example, 10:00:00 or 14:00:00 ? I presume it is 14:00:00 (the local time on the computer where digikam is running) but I would like the confirmation. -- You are receiving this mail because: You are watching all bug changes.
[digikam] [Bug 462916] Different renaming behaviors for video files depending of the device
https://bugs.kde.org/show_bug.cgi?id=462916 --- Comment #18 from Maik Qualmann --- The two samples from here have the correct date (time zone is respected since Android was detected as a device. If you have a sample that you think digiKam is reporting an incorrect date, please provide it. Maik -- You are receiving this mail because: You are watching all bug changes.
[digikam] [Bug 462916] Different renaming behaviors for video files depending of the device
https://bugs.kde.org/show_bug.cgi?id=462916 --- Comment #17 from mahikeulbody --- > The problem is fixed for digiKam-8.0.0. Indeed, now I have the same behavior for the Pixel 5 as the Moto G6. > The problem is that when time zone information is available, other users want > it to be displayed in the correct local time as well. Let says my local TZ is UTC+1 and I have a file with exif date = 10:00:00 UTC-3 What time digikam displays (and uses to renaming) : 10:00:00 or 14:00:00 ? (I presume it is 14:00:00) (I don't have a non-android camera allowing TZ so I cannot do the test (and I found nothing about that in the doc) -- You are receiving this mail because: You are watching all bug changes.
[digikam] [Bug 462916] Different renaming behaviors for video files depending of the device
https://bugs.kde.org/show_bug.cgi?id=462916 Maik Qualmann changed: What|Removed |Added Version Fixed In||8.0.0 -- You are receiving this mail because: You are watching all bug changes.
[digikam] [Bug 462916] Different renaming behaviors for video files depending of the device
https://bugs.kde.org/show_bug.cgi?id=462916 --- Comment #16 from mahikeulbody --- (In reply to Maik Qualmann from comment #15) > The phone wrote this time information in the video, neither ExifTool nor we > can evaluate more: 2022-12-12T19:03:49.00Z > The "Z" at the end means it should be UTC. > > Maik Ok, I understood. Therefore, to say "the Motorola video has a time zone info (Z) in the date, so digiKam can determine the correct local time" is not correct since most QuickTime videos seems to set UTC time (some with Z tag, others without Z), regardless of local time, following the recommendation of QuickTime developper doc to set UTC time. Consequently I think I will adjust time of my videos with Digikam to match the local time they were taken before to rename them. Thank you for all these answers. -- You are receiving this mail because: You are watching all bug changes.
[digikam] [Bug 462916] Different renaming behaviors for video files depending of the device
https://bugs.kde.org/show_bug.cgi?id=462916 --- Comment #15 from Maik Qualmann --- The phone wrote this time information in the video, neither ExifTool nor we can evaluate more: 2022-12-12T19:03:49.00Z The "Z" at the end means it should be UTC. Maik -- You are receiving this mail because: You are watching all bug changes.
[digikam] [Bug 462916] Different renaming behaviors for video files depending of the device
https://bugs.kde.org/show_bug.cgi?id=462916 --- Comment #14 from mahikeulbody --- Created attachment 154543 --> https://bugs.kde.org/attachment.cgi?id=154543=edit file taken at 16:03 (UTC-3) on a moto G6 set to UTC-3 -- You are receiving this mail because: You are watching all bug changes.
[digikam] [Bug 462916] Different renaming behaviors for video files depending of the device
https://bugs.kde.org/show_bug.cgi?id=462916 --- Comment #13 from mahikeulbody --- (In reply to Maik Qualmann from comment #7) > The problem is they break it down to UTC. However, the Motorola video has a > time zone info (Z) in the date, so digiKam can determine the correct local > time. I set my Moto g6 to UTC-3. At 15:42 (time displayed on the phone), I toke the video attached. Since, according to you, there is a time zone info in the date, I was expecting Digikam rename the file with its local time, 15:42. But in fact it renames the file with 19:42 which is the corresponding UTC+1 time (as the time zone of the computer where Digikam is running) but not the correct local time of the video. -- You are receiving this mail because: You are watching all bug changes.
[digikam] [Bug 462916] Different renaming behaviors for video files depending of the device
https://bugs.kde.org/show_bug.cgi?id=462916 Maik Qualmann changed: What|Removed |Added Status|REPORTED|RESOLVED Resolution|--- |FIXED --- Comment #12 from Maik Qualmann --- (In reply to mahikeulbody from comment #10) > So, if both files have time zone, why the difference in the renaming ? The difference came because digiKam didn't recognize the Pixel5 as an Android device, then we don't remove the time zone information. Keep in mind that everything has to work not only with smartphones, but also with camera devices and there are other peculiarities of the manufacturers. The problem is fixed for digiKam-8.0.0. Maik -- You are receiving this mail because: You are watching all bug changes.
[digikam] [Bug 462916] Different renaming behaviors for video files depending of the device
https://bugs.kde.org/show_bug.cgi?id=462916 --- Comment #11 from Maik Qualmann --- (In reply to mahikeulbody from comment #10) > So, if both files have time zone, why the difference in the renaming ? > > > it is no problem in digiKam-8.0.0 to take over the time information from > > ExifTool [...] however it would then probably always be UTC. > > In fact, no ; you could use this syntax : exiftool "-filename -api=QuickTimeUTC > > Phil Harvey said : "According to the specification, integer-format QuickTime > date/time tags should be stored as UTC. Unfortunately, digital cameras often > store local time values instead (presumably because they don't know the time > zone). For this reason, by default ExifTool does not assume a time zone for > these values. However, if the QuickTimeUTC API option is set, then ExifTool > will assume these values are properly stored as UTC, and will convert them > to local time when extracting." -- You are receiving this mail because: You are watching all bug changes.
[digikam] [Bug 462916] Different renaming behaviors for video files depending of the device
https://bugs.kde.org/show_bug.cgi?id=462916 mahikeulbody changed: What|Removed |Added Status|RESOLVED|REPORTED Resolution|FIXED |--- Version Fixed In|8.0.0 | Latest Commit|https://invent.kde.org/grap | |hics/digikam/commit/2f439eb | |2f3d1fd0aca1f5b8cdcf8e06bc0 | |5f5139 | --- Comment #10 from mahikeulbody --- I fail to see the time zone in the output of exiftool but I presume you checked with an hexa viewer. > the Motorola video has a time zone info > Pixel5 has a time zone information So, if both files have time zone, why the difference in the renaming ? > it is no problem in digiKam-8.0.0 to take over the time information from > ExifTool [...] however it would then probably always be UTC. In fact, no ; you could use this syntax : exiftool "-filename
[digikam] [Bug 462916] Different renaming behaviors for video files depending of the device
https://bugs.kde.org/show_bug.cgi?id=462916 Maik Qualmann changed: What|Removed |Added Version Fixed In||8.0.0 Resolution|--- |FIXED Latest Commit||https://invent.kde.org/grap ||hics/digikam/commit/2f439eb ||2f3d1fd0aca1f5b8cdcf8e06bc0 ||5f5139 Status|REPORTED|RESOLVED --- Comment #9 from Maik Qualmann --- Git commit 2f439eb2f3d1fd0aca1f5b8cdcf8e06bc05f5139 by Maik Qualmann. Committed on 11/12/2022 at 19:13. Pushed by mqualmann into branch 'master'. add more possible metadata to detect Android phone FIXED-IN: 8.0.0 M +1-1NEWS M +6-2core/libs/metadataengine/dmetadata/dmetadata_video.cpp https://invent.kde.org/graphics/digikam/commit/2f439eb2f3d1fd0aca1f5b8cdcf8e06bc05f5139 -- You are receiving this mail because: You are watching all bug changes.
[digikam] [Bug 462916] Different renaming behaviors for video files depending of the device
https://bugs.kde.org/show_bug.cgi?id=462916 --- Comment #8 from Maik Qualmann --- Pixel5 has a time zone information... Maik -- You are receiving this mail because: You are watching all bug changes.
[digikam] [Bug 462916] Different renaming behaviors for video files depending of the device
https://bugs.kde.org/show_bug.cgi?id=462916 --- Comment #7 from Maik Qualmann --- The problem is they break it down to UTC. However, the Motorola video has a time zone info (Z) in the date, so digiKam can determine the correct local time. The Pixel5 has no time zone information (a bug report to Google is due). This leads to the difference. The problem is that when time zone information is available, other users want it to be displayed in the correct local time as well. It is no problem in digiKam-8.0.0 to take over the time information from ExifTool (we use a combined parser from FFmpeg and ExifTool for video), however it would then probably always be UTC. Maik -- You are receiving this mail because: You are watching all bug changes.
[digikam] [Bug 462916] Different renaming behaviors for video files depending of the device
https://bugs.kde.org/show_bug.cgi?id=462916 --- Comment #6 from mahikeulbody --- Just in case that would be useful : I am using exiftool v12.50. -- You are receiving this mail because: You are watching all bug changes.
[digikam] [Bug 462916] Different renaming behaviors for video files depending of the device
https://bugs.kde.org/show_bug.cgi?id=462916 --- Comment #5 from mahikeulbody --- Renaming with exiftool is correct : exiftool "-filename both files are "UTC" named exiftool "-filename both files are "UTC+1" named May be it is an exiv2 problem ? (I presume that Digikam still uses exiv2) -- You are receiving this mail because: You are watching all bug changes.
[digikam] [Bug 462916] Different renaming behaviors for video files depending of the device
https://bugs.kde.org/show_bug.cgi?id=462916 --- Comment #4 from mahikeulbody --- Created attachment 154507 --> https://bugs.kde.org/attachment.cgi?id=154507=edit pixel 5 video file -- You are receiving this mail because: You are watching all bug changes.
[digikam] [Bug 462916] Different renaming behaviors for video files depending of the device
https://bugs.kde.org/show_bug.cgi?id=462916 --- Comment #3 from mahikeulbody --- Created attachment 154506 --> https://bugs.kde.org/attachment.cgi?id=154506=edit moto g6 video file -- You are receiving this mail because: You are watching all bug changes.
[digikam] [Bug 462916] Different renaming behaviors for video files depending of the device
https://bugs.kde.org/show_bug.cgi?id=462916 Maik Qualmann changed: What|Removed |Added CC||metzping...@gmail.com --- Comment #2 from Maik Qualmann --- We need the video files. The problem is that device manufacturers write their dates differently, sometimes including the time zone, sometimes not. The topic has been discussed endlessly, you can also find posts about it in the ExifTool forum. The detection has already been further improved in digiKam-8.0.0. Maik -- You are receiving this mail because: You are watching all bug changes.
[digikam] [Bug 462916] Different renaming behaviors for video files depending of the device
https://bugs.kde.org/show_bug.cgi?id=462916 --- Comment #1 from mahikeulbody --- Created attachment 154503 --> https://bugs.kde.org/attachment.cgi?id=154503=edit exiftool pixel 5 file -- You are receiving this mail because: You are watching all bug changes.
