Bug 518334 - Use QuickTime CreationDate if Present Rather Than CreateDate in MOV files
Summary: Use QuickTime CreationDate if Present Rather Than CreateDate in MOV files
Status: RESOLVED FIXED
Alias: None
Product: digikam
Classification: Applications
Component: Metadata-Video (other bugs)
Version First Reported In: 9.0.0
Platform: Microsoft Windows Microsoft Windows
: NOR normal
Target Milestone: ---
Assignee: Digikam Developers
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2026-03-30 14:44 UTC by bob.bourg
Modified: 2026-03-31 10:22 UTC (History)
0 users

See Also:
Latest Commit:
Version Fixed/Implemented In: 9.1.0
Sentry Crash Report:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description bob.bourg 2026-03-30 14:44:34 UTC
SUMMARY
 I request that the QuickTime metadata field CreationDate be used if present rather than QuickTime CreateDate in the digiKam the database for display and sorting of MOV files.

BACKGROUND
I believe based on observation and a search of other bugzilla reports that digiKam uses the QuickTime metadata field CreateDate when MOV files are scanned.  This field is UTC and contains no time zone info.  I believe that digiKam therefore applies a correction to the UTC time based on the current time zone of the computer when the file is added to the database.

I believe that newer Apple devices including iPhones now prioritize the field CreationDate over CreateDate.  CreationDate includes time zone information.  If CreationDate is present, this would allow digiKam to treat MOV files the same way as other image files that contain time zone information.  If CreationDate is not present, digiKam could default back to the way dates are currently being handled using CreateDate.

This issue became apparent when downloading iPhone Live Photos to a PC and scanning them in with digiKam.  Live Photos consist of a still HEIC image and a short 3-sec MOV video that are created at the same time.  If the Live Photo was taken in a different time zone than the digiKam computer is set to, the creation times for the HEIC and MOV files are different and therefore will sort out of order.  Use of CreationDate would fix this I believe.

I am attaching the HEIC and MOV files from a sample Live Photo.  The photo was taken with the iPhone set to the Paris time zone, and was downloaded to a computer set to New York.  (The time displayed on the clock in the image is Paris time - 4:26 pm or 16:26.)  I also am attaching a screenshot of digiKam after the file was scanned in.  Currently, a correction must be applied to the MOV date to allow them to be sorted together.  If my suggestion is implemented, digiKam would display Paris time for both files, since that was the local time of the phone when the photo was taken.  

Finally, I am attaching a screenshot of some info from an AI search regarding this subject.

SOFTWARE/OS VERSIONS
digiKam 9.0.0 - Windows version
Windows 11
Comment 1 bob.bourg 2026-03-30 14:52:14 UTC
I was unable to attach the MOV file due to its size.  Here is a link to the files on Google drive.  Let me know of any issues with accessing the file.

https://drive.google.com/drive/folders/1LHJ-_h4_9ykFcBgvbU0umuxU7pxisnfN?usp=sharing
Comment 2 Maik Qualmann 2026-03-30 19:32:53 UTC
Git commit 81e27a47b29eec4dd6997f525d2c00756fc2b434 by Maik Qualmann.
Committed on 30/03/2026 at 19:31.
Pushed by mqualmann into branch 'master'.

use converted QuickTime:CreationDate from ExifTool
FIXED-IN: 9.1.0

M  +1    -1    NEWS
M  +20   -0    core/libs/metadataengine/engine/metaengine_item.cpp

https://invent.kde.org/graphics/digikam/-/commit/81e27a47b29eec4dd6997f525d2c00756fc2b434
Comment 3 bob.bourg 2026-03-31 10:22:43 UTC
Thank you!