Created attachment 154502 [details] exiftool moto g6 file SUMMARY QuickTime format : all dates are UTC Renaming video files from two different devices (Motorola G6 and Google Pixel 5) produces different filenames : - one with UTC date - the other with UTC+1 (NB. my system is set on CET time which is = UTC+1) STEPS TO REPRODUCE 1. rename a pixel 5 video file with [date:yyyy-MM-dd_hh'h'mm-ss] 2. rename a moto g6 video file with [date:yyyy-MM-dd_hh'h'mm-ss] Instead of to attach a video file from each device, I attached the output of exiftool for each file. But I can provide also the video file if needed. OBSERVED RESULT for moto g6 : filename based on CreateDate + 01:00 for pixel 5 : filename based on CreateDate EXPECTED RESULT same result for both files either both filenames based on CreateDate either both filenames based on CreateDate + offset according the current time zone of the system SOFTWARE/OS VERSIONS Linux/KDE Plasma: Manjaro (available in About System) KDE Plasma Version: 5.26.4 KDE Frameworks Version: 5.100.0 Qt Version: 5.15.7 ADDITIONAL INFORMATION
Created attachment 154503 [details] exiftool pixel 5 file
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
Created attachment 154506 [details] moto g6 video file
Created attachment 154507 [details] pixel 5 video file
Renaming with exiftool is correct : exiftool "-filename<CreateDate" .mp4 => both files are "UTC" named exiftool "-filename<CreateDate" -api=QuickTimeUTC *.mp4 => both files are "UTC+1" named May be it is an exiv2 problem ? (I presume that Digikam still uses exiv2)
Just in case that would be useful : I am using exiftool v12.50.
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
Pixel5 has a time zone information... Maik
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 -1 NEWS M +6 -2 core/libs/metadataengine/dmetadata/dmetadata_video.cpp https://invent.kde.org/graphics/digikam/commit/2f439eb2f3d1fd0aca1f5b8cdcf8e06bc05f5139
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<CreateDate" -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."
(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<CreateDate" > -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."
(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
(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.
Created attachment 154543 [details] file taken at 16:03 (UTC-3) on a moto G6 set to UTC-3
The phone wrote this time information in the video, neither ExifTool nor we can evaluate more: 2022-12-12T19:03:49.000000Z The "Z" at the end means it should be UTC. Maik
(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.000000Z > 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.
> 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)
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
(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.