Summary: | inconsistent date for Dynamic Media:Shot Date in case of .mov video | ||
---|---|---|---|
Product: | [Applications] digikam | Reporter: | mahikeulbody <mcfarol84> |
Component: | Metadata-Xmp | Assignee: | Digikam Developers <digikam-bugs-null> |
Status: | RESOLVED FIXED | ||
Severity: | minor | CC: | metzpinguin |
Priority: | NOR | ||
Version: | 8.4.0 | ||
Target Milestone: | --- | ||
Platform: | Manjaro | ||
OS: | Linux | ||
Latest Commit: | https://invent.kde.org/graphics/digikam/-/commit/a355c119ecc28b09c3519a88c7d30be786d0398e | Version Fixed In: | 8.4.0 |
Sentry Crash Report: |
Description
mahikeulbody
2024-03-30 10:31:26 UTC
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 |