Bug 401964

Summary: Wrong datestamp video/mp4
Product: [Applications] digikam Reporter: Andrius <aegoreev>
Component: Albums-ItemsSortAssignee: Digikam Developers <digikam-bugs-null>
Status: RESOLVED FIXED    
Severity: normal CC: caulier.gilles, metzpinguin
Priority: NOR    
Version: 6.0.0   
Target Milestone: ---   
Platform: Microsoft Windows   
OS: Microsoft Windows   
Latest Commit: Version Fixed In: 6.2.0
Sentry Crash Report:

Description Andrius 2018-12-10 15:44:18 UTC
I have noticed that some of my MP4 videos files aren't sorted by date correctly still in digikam 6.0.0beta3.

Looks like Date Modified and Date Taken might be mixed up.
Comment 1 Andrius 2018-12-10 15:51:04 UTC
Here is a sample:
https://drive.google.com/file/d/1GyXBiejiOeamDGhPrTgFqIZC5UqlXIB-/view?usp=sharing

The video was taken on 2018-11-23 at 11-39am

digikam shows under the thumbnail:
2018-11-23  6:39PM
Mod. 2018-11-23 11:39AM

and in the right panel - caption - description:
2018-11-23 18:39:59
Comment 2 Maik Qualmann 2018-12-10 17:27:30 UTC
DigiKam is not wrong and displays the correct date and time, which is stored in the video (2018-11-23 6:39 PM (18:39).) Exiftool displays exactly the same creation date.

Maik
Comment 3 Andrius 2018-12-10 18:30:12 UTC
(In reply to Maik Qualmann from comment #2)
> DigiKam is not wrong and displays the correct date and time, which is stored
> in the video (2018-11-23 6:39 PM (18:39).) Exiftool displays exactly the
> same creation date.
> 
> Maik

Hi Maik
This video definitely was taken at 11-39am. I checked its properties in Android and Windows 10 and both show 11-39am.
Comment 4 Maik Qualmann 2018-12-10 20:05:54 UTC
I have just watched under Windows 10, here only the file date is displayed, which is the date for me today. As I said, digiKam and Exiftool read the creation date from the video metadata in the file. And that is clearly 18:39.

Maik
Comment 5 Andrius 2018-12-11 18:00:46 UTC
(In reply to Maik Qualmann from comment #4)
> I have just watched under Windows 10, here only the file date is displayed,
> which is the date for me today. As I said, digiKam and Exiftool read the
> creation date from the video metadata in the file. And that is clearly 18:39.
> 
> Maik

Maik,

Here is the output of Mediainfo:
https://pastebin.com/eBbPepvw
UTC 2018-11-23 18:39:59

exiftool:
https://pastebin.com/JSL6EtYh
2018:11:23 18:39:59
I think exiftool always shows time in UTC...
ffmpeg:
https://pastebin.com/5KDmEBiJ
2018-11-23T18:39:59.000000Z
I think Z stands for UTC
Comment 6 Maik Qualmann 2018-12-11 19:37:51 UTC
Right, the Z stands for UTC. And we deliberately ignore it because of bug reports. There are cameras that correctly encode the date/time in UTC, while others do not. These will append a Z to the date string even if they store locale time. We will not find a satisfactory solution here, in this case I consider Exiftool as a reference. Since Exiftool has no information (UTC, Z) we probably have a similar reason. You can adjust the digiKam timestamp with the Time Adjust tool (deactivate all checkboxes).

Maik
Comment 7 Andrius 2018-12-11 20:37:01 UTC
(In reply to Maik Qualmann from comment #6)
> Right, the Z stands for UTC. And we deliberately ignore it because of bug
> reports. There are cameras that correctly encode the date/time in UTC, while
> others do not. These will append a Z to the date string even if they store
> locale time. We will not find a satisfactory solution here, in this case I
> consider Exiftool as a reference. Since Exiftool has no information (UTC, Z)
> we probably have a similar reason. You can adjust the digiKam timestamp with
> the Time Adjust tool (deactivate all checkboxes).
> 
> Maik

Maik, thanks for your feedback. I hoped there will be some like 'if "Z" present then do "minus 7 hours"' but I guess it is more complicated than that. I can leave with manual adjustments. Looks like the way Android phones write the date stamp into video files changes over time too. Most of my videos are fine but the recent ones are all +7 hours. I guess I should report on Samsung Galaxy website.
Comment 8 Maik Qualmann 2019-03-28 21:05:20 UTC
We have a newer bug report because of the same problem. I close this bug, because in the new bug report many example video have been uploaded.

Maik

*** This bug has been marked as a duplicate of bug 405589 ***
Comment 9 caulier.gilles 2019-07-14 06:56:49 UTC
Fixed with #405589 and not reproducible with 6.2.0