I presume digikam applies a fuzzy logic to decide if the dates from videos are UTC or not. Whatever the case, it decided that the attached video (from a Ricoh GR II) is in local time so it displays all date fields (exif, iptc, xmp, ...) without offset, EXCEPT Dynamic Media:Shot Date which is displayed with an offset +1h (I am in UTC+1).
Video date-time is another big problem. We try to identify well-known cameras or manufacturers to convert from UTC or not. First of all, I don't know of any video files that contain time zone information. We can assume with Apple and Quicktime that it is a UTC date, just like with Android. This is a big problem with camera devices. Some use UTC but store local dates, others the other way around. I can see if I can include Ricoh in the detection. Maik
Well, this report is not about the right detection of type of device in relation to UTC (a big problem, I agree). It is about once Digikam make the decision to consider the dates as local time dates for a given file, it should to apply this decision on all dates displayed in the metadata panel for this file. It is indeed the case for all dates EXCEPT Dynamic Media:Shot Date.
> I can see if I can include Ricoh in the detection. Please don't change : Ricoh is detected as a "local time" device and it is the right decision. It is not the problem here.
Git commit a355c119ecc28b09c3519a88c7d30be786d0398e by Maik Qualmann. Committed on 30/03/2024 at 19:12. Pushed by mqualmann into branch 'master'. fix date representation of "Xmp.xmpDM.shotDate" FIXED-IN: 8.4.0 M +1 -1 NEWS M +1 -1 core/libs/metadataengine/dmetadata/dmetadata_video.cpp https://invent.kde.org/graphics/digikam/-/commit/a355c119ecc28b09c3519a88c7d30be786d0398e