Bug 490552 - Import: Incorrect date during automatic file naming with “date” construct
Summary: Import: Incorrect date during automatic file naming with “date” construct
Status: RESOLVED FIXED
Alias: None
Product: digikam
Classification: Applications
Component: Import-PostProcessing (show other bugs)
Version: 8.4.0
Platform: Ubuntu Linux
: NOR normal
Target Milestone: ---
Assignee: Digikam Developers
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2024-07-20 11:22 UTC by Ed Uscho
Modified: 2024-07-21 06:04 UTC (History)
1 user (show)

See Also:
Latest Commit:
Version Fixed In: 8.5.0
Sentry Crash Report:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Ed Uscho 2024-07-20 11:22:14 UTC
When importing files (images, videos) from a memory card or camera, you can automatically assign file names based on date information, for example. This is possible using the “date” construct. Example of such a pattern for file name creation:
[date:yyyyMMdd]_[date:hh]h[date:mm]m[date:ss]s__[file].[ext]

Speculation: I did not look into the code, but I assume that in the case of “date” the EXIF value “DateTimeOriginal” is used. If the file does not have EXIF data - e.g. for a video / MP4 - then presumably a file system timestamp is used?

With JPEG or raw images (files with EXIF metadata included) everything works perfectly.
In the case of MP4 videos, however, I get incorrect date values. In particular, the 'hour value' differs.

Example:
The source directory on a memory card contains the file 1Q0A2477.MP4 (see attachment). When I enter "ls -go 1Q0A2477.MP4" in the source directory, I get the following result:
-rwxr-xr-x 1 50182700 Jun 22 13:50 1Q0A2477.MP4
June 22, 13:50 is the correct time. At this point, the recording was actually made.

However, the file name naming pattern / token “[date:hh]” returns the wrong hour value 11 instead of 13.
In my case
[date:yyyyMMdd]_[date:hh]h[date:mm]m[date:ss]s__[file].[ext]
leads to
20240622_11h49m32s__1Q0A2475.MP4

Speculation: The cause could be, for example, incorrectly set time zones when reading/converting date values - e.g. when date strings are passed to date fields. UTC should be used here. However, it is striking that the minute value does not match either.

Time zone of my computer: UTC+2 (summertime in central Europe).

Wild speculation: The timestamp of the file system could have been interpreted as UTC when reading in (hour = 13) and when writing into the file name it could have been assumed that the 13 is UTC+2, whereby 2 hours were then subtracted from the 13 = 11 ... ???

SOFTWARE/OS VERSIONS
Linux: Ubuntu 22.04.4 LTS
KDE Plasma Version: 5.24.7
KDE Frameworks Version: 5.92.0
Qt Version: 5.15.3
Comment 1 Maik Qualmann 2024-07-20 11:46:06 UTC
The problem is known. We now only use ExifTool for the video date. However, there are two options. The QuickTime UTC date in the video files should be UTC, and it is also OK for smartphone videos. But there are also many camera devices that write UTC but set a local date. I have not yet set the ExifTool QuickTimeUTC flag, so no conversion is taking place. We will probably have to ignore users with incorrect UTC information in their camera devices.

Maik
Comment 2 Maik Qualmann 2024-07-21 06:04:05 UTC
Git commit a8267ecd1fa8fa87fd10991f92c8a0336edfb5ef by Maik Qualmann.
Committed on 21/07/2024 at 06:03.
Pushed by mqualmann into branch 'master'.

enable the QuickTimeUTC flag in ExifTool
FIXED-IN: 8.5.0

M  +1    -1    NEWS
M  +3    -1    core/libs/metadataengine/exiftool/exiftoolparser_command.cpp

https://invent.kde.org/graphics/digikam/-/commit/a8267ecd1fa8fa87fd10991f92c8a0336edfb5ef