MP4 Media create date

[twe]

Video and photos taken at the same time, have a one hour offset in Imatch, so renaming and sorting is problematic. I just did a test on Nikon Z6 and on a new Samsung S20 FE, and the create date is showing correct in Windows Explorer for MP4 files, but when importing to Imatch the metadata will have a 1 hour offset for video files, but photos have correct time. 

Since Windows Explorer get the correct time, I would like to find a solution in Imatch to get the correct create date and time on import, so that renaming and sorting will display photos and videos in correct order when sorting by capture time of filename etc. I can use Timewiz etc to correct this, but since the time is displayed correct in Windows Explorer file properties, it should also be correct in Imatch ?  Se attachments. Photo and video taken at the same time, have a 1 hour difference. Metadata browser in Imatch display the create time for video as 18:10 when in fact photo and video was taken at 19:10.

[ubacher]

The creation time in videos is given in UTC - I think this is some kind of standard.
I correct this by running a metadata template which takes the time given in the file name
and uses it to set the creation date/time.

I assume windows automatically corrects the time from UTC to local time.

[Mario]

Please provide sample files so I can analyze this.
Upload a file combination (image/video container) to your cloud space and post a link or send it to support email address.

IMatch uses ExifTool to extract the date and time, and if no time-zone offset is provided, IMatch must either assume the data is in UTC or in local time, depending on where the date and time information comes from (IPTC, EXIF, XMP, GPS, ...) I need to see which timestamps and in which format ExifTool returns the timestamps.
Since video files have neither EXIF nor XMP (usually), IMatch jumps through a lot of hoops to find the best possible timestamp for a given video container format. See also How IMatch uses Date and Time Information

[twe]

Ok, I will send sample files.

Samsung video files, has default filenames with the correct time: 20201026_191142.mp4, and Windos Explorer has the correct time, but the time in Metadata browser is only listed as UTC. So when I run my usual renaming it will change to 20201026_181149001.mp4

I might have to use TimeWiz on all my MP4 video files after import, and \ or create separate renaming presets for Nikon and for Samsung video...

By the way, when trying to fix this with TimeWiz I do not get the writeback pencil.

[Mario]

I have checked the QuickTime spec and I could not find anything about the dates being in UTC always.
Apple just refers to ISO 8601, which is also the date format used by ExifTool and IMatch. This is true for the QuickTime Create/Modify timestamps and also for the separate TRrack and Media Created/Modified timestamps.

This date format may contain a time-zone identifier like +01:00 or a Z for UTC.
If neither is specified, the time must/may be in local time?

Apple uses "2012-02-24T17:56Z" for a date of February 24, 2012, time of 17:56, UTC. as their example in the QT spec. The "Z" means UTC.

When IMatch looks at a create time QuickTime timestamp of "2018:02:03 09:57:04", how can it tell that this was recorded in UTC and not in local time? I checked two Z6 samples in my test library. One MP4 and one MOV.
IMatch assumes local time, Windows Explorer may be hard-coded to add the current time-zone? Not sure. If the timestamp would be "2018:02:03 09:57:04Z", things would be clear and well-defined.

Is there any spec from Apple that requires the MP4/MOV QuickTime timestamps to be in UTC? Link?

[Mario]

I'm not adverse to adding some sort of hard-coded offset, as a preference setting or something.
We already have a extra setting which controls whether to favor creation date over create date (Edit > Preferences > Metadata 2) - because some camera/device vendors seem to pick a random date...
Adding a "Add local time zone" or something could be doable...

[twe]

That would be a very useful new feature !
Remembering to do the same repetetive task of FIRST selecting all video files after import, adjust for local time in TimeWiz BEFORE renaming, has potential for a more efficient workflow.
I have renamed lots of photo and video files on import and all video files have wrong filename and a timeshift..so the sorting is wrong, but fixed manually today, so ok for now. I have also used Metadata Helper app, and set date & time from filrname (Samsung video).

A new preference choice of automatically adding local time zone to mp4 files on import would be a much better workflow.

[Mario]

I have added a feature to assume the time is in the local time-zone when importing timestamps from QuickTime metadata tags. Unless the tag has a time-zone indicator already (as it should - but some camera vendors don't bother).

[twe]

I did some more testing, and found that mp4 video files from Nikon Z6 have maker notes with time-zone indicator and correct create time.  Would be great to use this information for renaming and sorting.

[Mario]

This is an undocumented maker note and nothing I would base an implementation on.
I also don't see how this would relate to the Apple QuickTime maker notes. And Nikon does not document anything.

You can use this in your own custom variables, e.g. a metadata template or the TimeWiz, to produce something that specifically matches your camera and whatever the firmware stores in the metadata. IMatch gives you access to these maker notes via variables and also methods and functions to work with them in many features. That's far more most other software gives you.

I've spent a previous day already on this, implementation, testing and documenting the new "assume local time zone" feature. Because I think this might be useful for more than one user.
I won't spent more time adding features relying an a proprietary and undocumented maker note some Nikon cameras write. Feel free to use the tools and features already available in IMatch to utilize this tag. Variables allow for simple arithmetic like adding and subtracting, so you can use this in the TimeWiz to shift the timestamps as needed. Use a metadata template to do it automatically when IMatch is ingesting files. Or use the new feature available in the next release, which should do this.

Of course Nikon could also just do the right think, and store the QuickTime timestamps with a proper time-zone indicator, like "+01:00" in your case.