Video Equivalent of "DateTimeOriginal"?

[Roy Brian]

Hello!

In the vast array of time-related tags associated with a given picture, "DateTimeOriginal" is the usually the decisive one, in the sense that based on this tag, other websites and software (operating systems, Google Photos, Apple's Photos and more) will determine the photo's date and time and catalog it accordingly.

What's the equivalent of this tag in video files? When examining my GoPro videos I saw many candidates to this title, but couldn't reach a conclusion.

Here are those tags (there might be more, but those are the ones I managed to spot):

Code Select Expand

File Modification Date/Time
File Access Date/Time     
File Creation Date/Time   
Create Date               
Modify Date               
Track Create Date         
Track Modify Date         
Media Create Date         
Media Modify Date         

Thanks!

[TooManyPictures]

Hello,

I use MediaCreateDate or FileCreateDate for videos since many (or all) of them lack DateTimeOriginal

This is based on empirical data I encountered while trying to sort files from 12+ different devices.

[StarGeek]

Here are those tags (there might be more, but those are the ones I managed to spot):

Run exiftool -time:all -g1 -a -s FILE to see all the time tags and the groups they belong to.

I personally thing that CreateDate is probably the best.  With the command above, you'll see that there are multiple TrackCreateDate and MediaCreateDate tags, one for each track.  In a video taken straight from a camera, these probably are going to be the same as CreateDate, but if the video has been edited or if a track from some other video has been muxed in (think youtube video where the audio has been replaced by music or if a subtitle track has been added), it might be undependable.

@TooManyPictures suggestion of FileCreateDate is probably fine for a Windows system, but becomes problematic for a Mac and is non-existent on Linux, so if the file might be transferred to/from one of those systems, it becomes undependable.

[Roy Brian]

Thanks everyone.

Alright, then CreateDate it is!

Moreover:

1. Is it possible to append usercomment to a video?

2. I'm asking this specifically in the context of this thread, but the question is valid for all kinds of ExifTool manipulations:
How can I put a group of video files into folders, based on the years and months of a video's CreateDate?
ExifTool should refer to the years and months of the files only, and put them into folders accordingly, in the following naming format: yyyy-mm.

Thanks!

[StarGeek]

1. Is it possible to append usercomment to a video?

Maybe, sorta...

It depends upon multiple variables.  First, if exiftool can write to the file.  For example, if it's an MKV, then no.  But since you talk about Apple, I'm going to assume MP4/MOV.  In this case, exiftool can write to the XMP-exif:UserComment tag.  With regards to the EXIF:UserComment tag, EXIF blocks in video files aren't very common and exiftool can't create them.  The question then becomes whether the other programs you are using can read the XMP-exif:UserComment tag or not.

2. I'm asking this specifically in context of this thread, but the question is valid for all kinds of ExifTool manipulations:
How can I put a group of video files into folders, based on the years and months of a video's CreateDate?
ExifTool should refer to the years and months of the files only, and put them into folders accordingly, in the following naming format: yyyy-mm.

Take a look at the -d option, the Renaming examples, and the FileName and Directory tags pages for examples.

[Roy Brian]

Thanks! (I absolutely love this software!)

I adjusted the CreateDate value but Google Photos for some reason displays the time two hours late (all other values are correct).
I guess it's a timezone thing, as the video was taken in a different one (GMT+1) than where I'm now at (GMT+2). How can I fix that?

[StarGeek]

I don't know, as Google Photos and video files are not something I've extensively tested.  See this recent thread.

[Roy Brian]

Yep, Google Photos is indeed quite buggy. So I think I'll try first taking the "brute force" approach and simply changed every time-related tag to the desired value.
How do I do that quickly? (there are hundreds of those)
I noticed that many of the tags include a "+02:00" value that might confuse Google Photos.

[Roy Brian]

Well, I tried to "brute force" every date-time related tag with -time:all and -alldates but Google Photos displayed time is still two hours ahead.

I examined the file further and there are some tags with a +02:00 suffix, which I suspect causes the problem. For example:



I live in a UTC+02:00 time-zone, and that might explain the appearance of this, but the video was taken in a UTC+01:00 time-zone.

Anyhow, is it possible to simply remove any reference to a time-zone whatsoever, and simply store the date-time as is?

[Phil Harvey]

Sorry, I missed your question about how to set all date/time tags at once.

exiftool -wm w -time:all="SOME TIME" DIR

I doubt the time zone is confusing google, but you could try not including a time zone in the above command.  The FileXxxx times won't be affected by this command -- they are stored in the filesystem, not in the file itself.

- Phil

[Roy Brian]

Hi Phil,

Thanks for the reply.

For a bunch of videos, I want to apply the same date and time under the "Date Created" Finder column and apply it to all date/time tags using the command you specified.

Is this achievable?

Moreover, I guess what confuses Goolge Photos are the UTC values appended to the end of the actual date/time values. Is there's any way to simply erase the UTC values?
I don't see why they're even there, the true time where I live is the time pictured below WITHOUT the UTC values (in other words, the time shown below WITH the UTC values translates to two/three hours ahead of the current time here).

[Phil Harvey]

The file times are correct for your local system time.  The "+02:00" and "+03:00" just indicate the time zone that was active at that time.  So it would be 17:19:17 local time, and +02:00 indicates that this was 15:19:17 UTC.

To copy from the MacOS file creation time, do this:

exiftool -wm w "-time:all<MDItemFSCreationDate" DIR

If Google Photos doesn't like these times, then try adding -api QuickTimeUTC to the command.

- Phil

[Roy Brian]

Thanks for the reply Phil.

How do I set the time zone to +3 UTC for all date/time-related tags?

[Phil Harvey]

You don't.  If you are using -api QuickTimeUTC, then all QuickTime tags are stored in UTC, and converted to the local system time for display purposes.  So they will appear in whatever time zone you have set for your system.

- Phil

[Roy Brian]

And without using the -api QuickTimeUTC?

[Phil Harvey]

Then QuickTime tags wouldn't have a time zone.

Perhaps you are talking about some other date/time tags?  Use the -G0:1 option and tell me what groups they are in.

- Phil

[Roy Brian]

Thanks Phil.

1. Eventually, I'm trying to make Google Photos display the local time of a given video. If a video was taken at 3 PM in France and another at 8 AM in the USA, then Google Photos should show 3 PM and 8 AM, respectively. What causes the trouble I think might be the discrepancy between the EXIF date/time tags, which don't hold any time zone references whatsoever, and the Finder file properties, which contain the +03:00 values. So what I'm trying to do is to offset this by adding the +03:00 value to the EXIF values as well.

2. In what part of the command do I put -G0:1?

[Phil Harvey]

The command is:

exiftool -a -s -G0:1 -time:all FILE

This will show you all date/time tags and where they came from.

- Phil

[Roy Brian]

Thanks. Here you go:

Code Select Expand


[File:System]   FileModifyDate                  : 2018:01:19 17:21:01+02:00
[File:System]   FileAccessDate                  : 2018:03:23 20:23:07+03:00
[File:System]   FileInodeChangeDate             : 2018:03:23 19:21:13+03:00
[QuickTime]     CreateDate                      : 2015:01:12 16:57:37
[QuickTime]     ModifyDate                      : 2015:01:12 16:57:37
[QuickTime:Track1] TrackCreateDate              : 2015:01:12 16:57:37
[QuickTime:Track1] TrackModifyDate              : 2015:01:12 16:57:37
[QuickTime:Track1] MediaCreateDate              : 2015:01:12 16:57:37
[QuickTime:Track1] MediaModifyDate              : 2015:01:12 16:57:37
[QuickTime:Track2] TrackCreateDate              : 2015:01:12 16:57:37
[QuickTime:Track2] TrackModifyDate              : 2015:01:12 16:57:37
[QuickTime:Track2] MediaCreateDate              : 2015:01:12 16:57:37
[QuickTime:Track2] MediaModifyDate              : 2015:01:12 16:57:37
[QuickTime:Track3] TrackCreateDate              : 2015:01:12 16:57:37
[QuickTime:Track3] TrackModifyDate              : 2015:01:12 16:57:37
[QuickTime:Track3] MediaCreateDate              : 2015:01:12 16:57:37
[QuickTime:Track3] MediaModifyDate              : 2015:01:12 16:57:37
[QuickTime:Track4] TrackCreateDate              : 2015:01:12 16:57:37
[QuickTime:Track4] TrackModifyDate              : 2015:01:12 16:57:37
[QuickTime:Track4] MediaCreateDate              : 2015:01:12 16:57:37
[QuickTime:Track4] MediaModifyDate              : 2015:01:12 16:57:37


[Phil Harvey]

Right.  There are no time zones stored for any of these tags.  The system ones aren't part of the file, and they reflect only your system time zone.

- Phil

[Roy Brian]

So, do you have any idea how to solve this?

And how did the QuickTime stuff get there in the first place? Is it because I'm on a mac? The videos were taken with a GoPro, and then transferred directly to my MacBook. Nothing more.

[Phil Harvey]

QuickTime is the base format used for MP4 and many other types of videos, which is why these are in the QuickTime group.

It sounds like you want to adjust the QuickTime date/time tags according to your time zone.  The command would be something like this to subtract 2 hours from these times:

exiftool -quicktime:time:all-=2 FILE

- Phil

[Roy Brian]

Wouldn't it just set the time 2 hours behind the actual time?
The times shown above are the correct ones for that video. It's just that Google Photos show as if they were taken three hours later.

[Phil Harvey]

My suggestion was to shift the times before putting in Google Photos so it shows the correct time.  Am I missing something?  I thought this is what you wanted.  OK, 3 hours, not 2.

- Phil

[Roy Brian]

Hmm, to put things simply, I'm trying to figure out the following discrepancy:

Jan 12 2018, at 16:57:37 is the correct, actual time the video was taken.

The date/time were off by 3 years, so I applied -wm w -time:all="2018:01:12 16:57:37" to the file, and ExifTool as expected did its job well, as evident in the extracted value of -createDate:



However, this is what shows up in Google Photos. Everything's correct but the time, which is exactly three hours ahead.



The same happens with every video I've tried, so I guess I'm doing something wrong.

[Phil Harvey]

Did you ever try adding the -api quickTimeUTC option to the command when you are writing the time as I suggested?  We seem to be going around in circles.  Doing this will have the same effect as shifting the time by whatever time zone you are in.  The problem is that some software follows the QuickTime specification and stores times in UTC, and some doesn't.  I don't know what Google expects, you have to try it either way.

- Phil

[Roy Brian]

Hi Phil,

I just tried to implement what you suggested. The time is still off, albeit now by 1 hour (ahead).



This is the full command I typed in:

exiftool -wm w -api quickTimeUTC -time:all="2018:01:12 16:57:37" /Users/****/Desktop/538067733.081182.mp4

Thanks!

[Phil Harvey]

The 1 hour difference could be due to daylight savings time since we are in daylight savings time now but we weren't on Jan 12.

But knowing this doesn't help.  The solution is still the same: set the time to whatever you need so that google will display it properly.  I don't even know what time zone google is using.

- Phil

[Roy Brian]

I see. So you're suggesting to set the time one hour earlier than what it was actually?
It will indeed solve the Google Photos issue (at least while we're in daylight savings time), but may cause problems with other platforms.

[Phil Harvey]

I'm saying that this is the only way you'll get it to display properly in Google Photos.  If you use other software that displays it differently, then there is probably no way to get them all to agree on the proper time.  But you don't need to worry about that if you are only using Google Photos.

- Phil

[Roy Brian]

Thanks for the help. I think I'd rather set the true time and just live with the 1-hour offset.

Anyway, I made a small list containing all ExifTool commands that were suggested as various solutions in the recent topics I opened here. To maximize my learning, I'm going to utilize this discussion to ask for some explanations for the following:

Code Select Expand


-v ARGS | grep -E "(Error|Nothing)"
FindStr
-v2
-progress
-g1
-a
-s
-wm w
-G0:1
-a
-s


And, I would love to hear some more about the usage of < or > and -TagsFromFile @.

Is there a page listing ALL ExifTool commands with an explanation (and usage example) for each?

[Phil Harvey]

This is all explained in the exiftool application documentation (download in PDF format).

You can also see this documentation by running exiftool with no arguments.

I don't know about FindStr though, and "grep" is another utility that has its own documentation.

- Phil

[Roy Brian]

Thanks a lot, Phil.

And a small update:

Apple Photos also shows the videos with an offset of 2 hours:



No matter what the command is. It's driving me crazy. Should I just live with it?
A makeshift solution would be to set -time:all= two hours behind, but I'm afraid it would "get back" at me one day should those services should get repaired.
I believe it all stems from the +03:00 values in those 3 believes. If only there was a way to remove those...

[Phil Harvey]

It looks to me as if Apple Photos is doing the correct thing, and should agree with ExifTool if you use the -api quicktimeutc option, which is actually per the QuickTime specification (but not the default in ExifTool because most cameras don't write it this way).

- Phil

[Roy Brian]

Hi Phil,

I'm helpless. Google Photos shows the time of video as if it was taken three hours ahead; Apple's Photos shows two hours (I guess the 1-hour difference between the apps comes from DST observation in Google Photos).
Using -wm w -api quickTimeUTC doesn't change the output, so I was using what I'd figure to be simplest command to set all times correctly: exiftool -time:all=. Doesn't help anyway.
There are only 2 ways I could think of that would circumvent this and show the video's true time: either use exiftool -time:all= to set the time to be 3 hours earlier than what it really was, or, in Google Photos, set the time zone to be to be GMT+00:00. Both are less than ideal solutions, of course.

[Phil Harvey]

I can't reproduce your problem with Apple Photos.  The date/time it displayed by Apple Photos was the same as I set with this command:

exiftool -wm w -time:all="2017:01:02 03:04:05" -api quicktimeutc test.mp4

And ExifTool shows this:

Code Select Expand

> exiftool -api quicktimeutc -time:all -G1 -a test.mp4
[System]        File Modification Date/Time     : 2018:04:02 10:55:05-04:00
[System]        File Access Date/Time           : 2018:04:02 10:56:25-04:00
[System]        File Inode Change Date/Time     : 2018:04:02 10:55:22-04:00
[QuickTime]     Create Date                     : 2017:01:02 03:04:05-05:00
[QuickTime]     Modify Date                     : 2017:01:02 03:04:05-05:00
[Track1]        Track Create Date               : 2017:01:02 03:04:05-05:00
[Track1]        Track Modify Date               : 2017:01:02 03:04:05-05:00
[Track1]        Media Create Date               : 2017:01:02 03:04:05-05:00
[Track1]        Media Modify Date               : 2017:01:02 03:04:05-05:00
[Track2]        Track Create Date               : 2017:01:02 03:04:05-05:00
[Track2]        Track Modify Date               : 2017:01:02 03:04:05-05:00
[Track2]        Media Create Date               : 2017:01:02 03:04:05-05:00
[Track2]        Media Modify Date               : 2017:01:02 03:04:05-05:00

My current time zone is -04:00, and on Jan 2 it was -05:00.

- Phil

[Roy Brian]

Eureka! I saw your comment and decided (for some reason, maybe our of despair) to give this command a shot:

Code Select Expand

exiftool -api quicktimeutc -time:all+="3:0:0 0:0:0" -G1 -a
And guess what, it worked!
Apple Photos now shows the correct time, and Google Photos shows an offset a just an extra hour. I think I could live with that. Any idea what happened here?

[Phil Harvey]

There seem to be a number of things that don't add up each time you post:

Eureka! I saw your comment and decided (for some reason, maybe our of despair) to give this command a shot:

Code Select Expand

exiftool -api quicktimeutc -time:all+="3:0:0 0:0:0" -G1 -a

1. -api quicktimeutc  will make no difference when just shifting times

2. -time:all+="3:0:0 0:0:0"  will add 3 years to the date/times

3. -G1 -a  are meaningless options when writing

- Phil

[Roy Brian]

You're right, I apologize, I was so excited upon reaching a solution that I forgot to mention a few facts:

When I first noticed those imprecisions with the videos, with the limited ExifTool knowledge I have, I used exiftool -time:all to check the video's date/time values, and as you can see, only the years appear to be incorrect. The time is fine (the video was taken at 2018:01:06 14:16:15).



So when I saw the command you used yourself for testing (exiftool -api quicktimeutc -time:all -G1 -a), and gave it a shot, I saw that not only the date was off by 3 years, but so does the time - by two hours!



That's what I've been seeing in Apple Photos (and Google Photos adds an additional hour, probably due to DST observation). So every time I typed exiftool -api quicktimeutc -time:all+="3:0:0 0:0:0" -G1 -a, apparently I should have decreased two hours from the time as well.

Still, Google Photos adds an additional hour, but I think I can live with that.

I have no idea how did that 16:16:15 got there in the first place. And, how come there are such critical discrepancies between dates inside the same file?

Moreover, from now on, should I use -quicktime utc to check and edit the values of every video I have?

Thanks!

[Phil Harvey]

I see no discrepancies.  Everything is consistent with your camera clock being set to the correct day/time in 2015 instead of 2018, and the camera not knowing the time zone.  Since the camera doesn't know the time zone, it stores the times as local time instead of UTC.  But Apple Photos does know the time zone, and assumes the times in the videos are UTC, so you get this difference when it shows them in the local system time zone.  If you set your camera to the correct UTC time, then Apple Photos should show the correct time.  ExifTool should be used with the -api quicktimeutc option (when reading and writing) to agree with Apple Photos, or without the -api quicktimeutc option to agree with what the camera displays.  (Hence the need for the -api quicktimeutc option.)

[Roy Brian]

Thanks Phil.

That's odd because some of the videos were taken with the newest GoPro model which offers Geotagging capabilities for media.

Anyway, do you believe Google Photos relies on -api quicktimeutc as well?

[Phil Harvey]

I would think that Google Photos assumes the times are stored as UTC, but they may have a bug with their handling of daylight savings times.