Quicktime:CreateDate versus Windows Media Created

[mcwieger]

I have a workflow to update video file metadata as follows:
- Set correct date in Windows Photo Gallery (yes, ancient and EoL). This is stored in Windows field Media Created.
- Set all file date fields in Advanced Renamer (Date Created, Date Modified)
- Set all date tags in Exiftool using

Code Select Expand

exiftool.exe -P -v2 "-quicktime:CreateDate<FileModifyDate" "-quicktime:ModifyDate<FileModifyDate" "-quicktime:TrackCreateDate<FileModifyDate" "-quicktime:TrackModifyDate<FileModifyDate" "-quicktime:MediaCreateDate<FileModifyDate" "-quicktime:MediaModifyDate<FileModifyDate" "video.mp4"
This sets all relevant date fields correctly, including Quicktime:CreateDate. However, the Windows Media Create field is showing a value that is two hours later.

Pretty sure it has to do with Timezone (currently in CET +2.00) and when check my pictures in my photo apps (Synology Photo Station and PiGallery2) it shows the correct time.

Still, I would like to see if my Exiftool command can be changed so it displays both Quicktime as well as the Windows time correctly.

Any help appreciated.

[wywh]

Add this to the command when writing or reading .mp4, .m4v and .mov:

-api QuickTimeUTC=1

- Matti

[mcwieger]

The result is that the Windows Media Created date is now correct, but the others are not (the top date is the correct one):

Code Select Expand

[System]        FileModifyDate                  : 2023:04:21 18:53:30+02:00
[System]        FileAccessDate                  : 2023:07:27 15:38:30+02:00
[System]        FileCreateDate                  : 2023:07:27 14:17:43+02:00
[QuickTime]    CreateDate                      : 2023:04:21 16:53:30
[QuickTime]    ModifyDate                      : 2023:04:21 16:53:30
[UserData]      ContentCreateDate              : 2023:04:21 16:53:30Z
[UserData]      ContentCreateDate              : 2023:04:21 16:53:30Z
[Track1]        TrackCreateDate                : 2023:04:21 16:53:30
[Track1]        TrackModifyDate                : 2023:04:21 16:53:30
[Track1]        MediaCreateDate                : 2023:04:21 16:53:30
[Track1]        MediaModifyDate                : 2023:04:21 16:53:30
[Track2]        TrackCreateDate                : 2023:04:21 16:53:30
[Track2]        TrackModifyDate                : 2023:04:21 16:53:30
[Track2]        MediaCreateDate                : 2023:04:21 16:53:30
[Track2]        MediaModifyDate                : 2023:04:21 16:53:30

[Phil Harvey]

You have to also use -api quicktimeutc when extracting the tags.

- Phil

[mcwieger]

Aha, clear. Thank you.

Indeed then it's shown correctly in Exiftool. However, now one photo app (Synology Photo Station) is showing the correct date, PiGallery2 showing the wrong one (16:53:30)...

Guess I'll have to request a fix with them...

[Phil Harvey]

As you have learned, unfortunately the use of the time zone for QuickTime-format videos (MOV, MP4, M4V, etc) is inconsistent.  This is because the specification called for all times to be stored in UTC, but early cameras (and still some current camera) only know about local time, so they can't possibly follow the specification.  For this reason, ExifTool doesn't assume they are stored as UTC unless you tell it.  It isn't really a bug if other apps do this differently -- it depends on their user base and which method applies best to them.

When the ability to read QuickTime-format files was added to ExifTool, local time was more common.  But now I think that UTC has become more common.  If I wrote ExifTool now, UTC would have been the default.

- Phil