How does the quicktimeUTC option work when included as part of a command like this:
/usr/local/bin/exiftool -d /Volumes/G-DRIVE/Media/video/%Y/%m/%Y-%m-%d_at_%Hh%Mm%Ss -overwrite_original -api QuickTimeUTC '-filename<${filemodifydate}_${mediadatasize#}.%e' '-filename<${DateCreated}_${mediadatasize#}.%e' '-filename<${CreationDate}_${mediadatasize#}.%e' '-filename<${CreateDate}_${mediadatasize#}.%e' '-filename<${DateTimeOriginal}_${mediadatasize#}.%e' '-filemodifydate<DateCreated#' '-filemodifydate<CreationDate#' '-filemodifydate<CreateDate#' '-filemodifydate<DateTimeOriginal#'
I'm running into an issue where QuickTime videos are not being parsed right due to the time zone issue. I'm not only parsing QuickTime files, though, so need a command that will work no matter the type of video file (thus the various backup options for the date). Some of the dates are in local time and others are in UTC, though. Will the API QuickTimeUTC option mess up parsing if used on a date tag that's already in local time?
Example tags from a QuickTime file, where the correct time is indicated by the Creation Date (2023:01:31 20:04:56-05:00), but the other tags have UTC time and would be incorrect if interpreted as local time. So, will the QuickTimeUTC option necessarily cause ALL tags to be interpreted as UTC, even the tags that are explicitly in local time?
File Modification Date/Time : 2023:02:01 01:04:56-05:00
Create Date : 2023:02:01 01:04:56
Track Create Date : 2023:02:01 01:04:56
Media Create Date : 2023:02:01 01:04:56
Creation Date : 2023:01:31 20:04:56-05:00
The -api QuickTimeUTC option (https://exiftool.org/ExifTool.html#QuickTimeUTC) only affects integer based Quicktime time stamps and doesn't affect any other date/time tags. When you check a tag on the Quicktime tags page (https://exiftool.org/TagNames/QuickTime.html), there will be a note that tells you if the QuickTimeUTC option will affect the tag or not.