News:

2023-03-15 Major improvements to the new Geolocation feature

Main Menu

iOS 9 new [Keys] CreationDate tag

Started by wywh, May 14, 2020, 01:40:20 PM

Previous topic - Next topic

wywh

Hello,

I noticed that iOS (8.4)-9 or greater movies seem to have a new datetime tag:

[Keys] CreationDate: 2020:01:01 12:00:00+02:00

It can be inserted to old iOS movies and other movies with:

exiftool -m -P -overwrite_original_in_place -Keys:CreationDate="2020:01:01 12:00:00+02:00" movie.mov

(Final Cut Pro 10.4.8 m4v movies fail without the -m switch).

Is there an option to set the DST timezone according to the date for that tag in a similar way like "exiftool -api QuickTimeUTC=1" seems to do automatically?

It seems macOS 10.15 Catalina's Photos.app 5.0 readily grabs the datetime from that tag. On the other hand macOS 10.14 Mojave's Photos.app 4.0 behaves differently.

Does anyone outside Apple know which algorithm each Photos.app version uses when setting the datetime to the imported movies? Which datetime metadata does it use and in which order??

Would it be a good idea to insert that tag to all movies and modify all other datetime tags (QuickTime, XMP etc) the same in case some application besides Photos.app gets the datetime from some other field? Or would that only muddy current movie datetime mess even more?

regards,

- Matti

StarGeek

Quote from: wywh on May 14, 2020, 01:40:20 PM
I noticed that iOS (8.4)-9 or greater movies seem to have a new datetime tag:

The fact that it's being set may be new, but that tag has been around for quite a while.

QuoteDoes anyone outside Apple know which algorithm each Photos.app version uses when setting the datetime to the imported movies? Which datetime metadata does it use and in which order??

This is probably something that you'll have to figure out yourself.  I've tested some Windows stuff, but I don't use a Mac.

QuoteWould it be a good idea to insert that tag to all movies and modify all other datetime tags (QuickTime, XMP etc) the same in case some application besides Photos.app gets the datetime from some other field? Or would that only muddy current movie datetime mess even more?

It's pretty much up to you depending upon what programs you use and what the intended purpose of your files is.  If the files are intended to be shared with people who might care about the metadata, for example, on some stock image/footage site, then more metadata would probably be better.  If you plan on using Adobe programs, then you would want to add the XMP tags.  But the more data you add the more you'll have to work to keep it in sync.

Myself, I don't do much video, though I do capture some live steams occasionally.  In those cases I make sure I set the Quicktime:CreateDate and that's about it. My DAM reads that and that's good enough for me.
* Did you read FAQ #3 and use the command listed there?
* Please use the Code button for exiftool code/output.
 
* Please include your OS, Exiftool version, and type of file you're processing (MP4, JPG, etc).

Phil Harvey

Hi Matti,

Quote from: wywh on May 14, 2020, 01:40:20 PM
Is there an option to set the DST timezone according to the date for [CreationDate] in a similar way like "exiftool -api QuickTimeUTC=1" seems to do automatically?

No.  This tag is stored as text with time zone, so that time zone is what you get.

QuoteIt seems macOS 10.15 Catalina's Photos.app 5.0 readily grabs the datetime from that tag. On the other hand macOS 10.14 Mojave's Photos.app 4.0 behaves differently.

Not surprising.  Apple isn't known for their consistency.

QuoteDoes anyone outside Apple know which algorithm each Photos.app version uses when setting the datetime to the imported movies? Which datetime metadata does it use and in which order??

Not me for sure.

QuoteWould it be a good idea to insert that tag to all movies and modify all other datetime tags (QuickTime, XMP etc) the same in case some application besides Photos.app gets the datetime from some other field? Or would that only muddy current movie datetime mess even more?

I can't answer that.

- Phil
...where DIR is the name of a directory/folder containing the images.  On Mac/Linux/PowerShell, use single quotes (') instead of double quotes (") around arguments containing a dollar sign ($).

wywh

Filename YYYY-MMDD-hhmm-ss.* has been my golden standard for image and movie datetimes and I'd like all other metadata including file creation & modification datetimes to be the same. Images and movies should sort together everywhere regardless of DST or location. Images are OK but movie datetimes are giving me lots of headache and confusion.

I am trying to build a command that sets (H.264 m4v, mp4, mov) movie times so that all my applications including Photos.app 5.0 read them correctly. Photos.app seems to prioritize that "Keys > CreationDate" so also it must be modified. Standards should be used for future proofing.

My current plan to insert filenames to metadata is:

exiftool -m -P -overwrite_original_in_place -wm w -api QuickTimeUTC=1 "-AllDates<filename" "-Track*Date<filename" "-Media*Date<filename" movie.mov

Is there a better way to modify the QuickTime Tracks or does any application pay attention to their datetimes?

What option should be used to set the "Keys > CreationDate" with a timezone like +02:00? That tag needs a timezone because I noticed that Photos 5.0 datetime is scrambled and the year set to something like "177294" in mp4 and m4v if "Keys > CreationDate" or "UserData > DateTimeOriginal" is without timezone.

Some commands like "-AllDates<filename" create "UserData > DateTimeOriginal" without timezone. Is it best to use "-wm w" so no such unexpected tags are created? Or is it possible to force adding a timezone there?

BTW, why deleting "Keys > CreationDate" tag also deletes Composite > GPS* locations?

A related question: In Canon 6D movies some apps seem to stubbornly get some datetimes from either "IFD0 > ModifyDate" or "ExifIFD > DateTimeOriginal". I have unsuccessfully tried to modify them the same as other datetimes or wipe them out. Any advice for that?

How can I combine following two commands so that also Keys get the datetime from the filename with timezone and DST info?

exiftool -m -P -overwrite_original_in_place -wm w -api QuickTimeUTC=1 "-AllDates<filename" "-Track*Date<filename" "-Media*Date<filename" 2020-0101-1200-00_iphone4s_ios9.3.2.mov

exiftool -m -P -overwrite_original_in_place -Keys:CreationDate="2020:01:01 12:00:00+02:00" 2020-0101-1200-00_iphone4s_ios9.3.2.mov

iOS 9 or greater seem to have the Keys tag:

exiftool -a -G1 -s -time:all 2020-0101-1200-00_iphone4s_ios9.3.2.mov
[System]        FileModifyDate                  : 2020:01:01 12:00:00+02:00
[System]        FileAccessDate                  : 2020:05:16 17:00:27+03:00
[System]        FileInodeChangeDate             : 2020:05:16 20:49:41+03:00
[QuickTime]     CreateDate                      : 2020:01:01 10:00:00
[QuickTime]     ModifyDate                      : 2020:01:01 10:00:00
[Track1]        TrackCreateDate                 : 2020:01:01 10:00:00
[Track1]        TrackModifyDate                 : 2020:01:01 10:00:00
[Track1]        MediaCreateDate                 : 2020:01:01 10:00:00
[Track1]        MediaModifyDate                 : 2020:01:01 10:00:00
[Track2]        TrackCreateDate                 : 2020:01:01 10:00:00
[Track2]        TrackModifyDate                 : 2020:01:01 10:00:00
[Track2]        MediaCreateDate                 : 2020:01:01 10:00:00
[Track2]        MediaModifyDate                 : 2020:01:01 10:00:00
[Track3]        TrackCreateDate                 : 2020:01:01 10:00:00
[Track3]        TrackModifyDate                 : 2020:01:01 10:00:00
[Track3]        MediaCreateDate                 : 2020:01:01 10:00:00
[Track3]        MediaModifyDate                 : 2020:01:01 10:00:00
[Track4]        TrackCreateDate                 : 2020:01:01 10:00:00
[Track4]        TrackModifyDate                 : 2020:01:01 10:00:00
[Track4]        MediaCreateDate                 : 2020:01:01 10:00:00
[Track4]        MediaModifyDate                 : 2020:01:01 10:00:00
[Keys]          CreationDate                    : 2020:01:01 12:00:00+02:00

Those stubborn Canon "IFD0 > ModifyDate" or "ExifIFD > DateTimeOriginal" tags:

exiftool -a -G1 -s -time:all 2020-0101-1200-00_canon6d.mov
[System]        FileModifyDate                  : 2020:01:01 12:00:00+02:00
[System]        FileAccessDate                  : 2020:05:16 17:00:32+03:00
[System]        FileInodeChangeDate             : 2020:05:16 20:55:40+03:00
[QuickTime]     CreateDate                      : 2020:01:01 10:00:00
[QuickTime]     ModifyDate                      : 2020:01:01 10:00:00
[Track1]        TrackCreateDate                 : 2020:01:01 10:00:00
[Track1]        TrackModifyDate                 : 2020:01:01 10:00:00
[Track1]        MediaCreateDate                 : 2020:01:01 10:00:00
[Track1]        MediaModifyDate                 : 2020:01:01 10:00:00
[Track2]        TrackCreateDate                 : 2020:01:01 10:00:00
[Track2]        TrackModifyDate                 : 2020:01:01 10:00:00
[Track2]        MediaCreateDate                 : 2020:01:01 10:00:00
[Track2]        MediaModifyDate                 : 2020:01:01 10:00:00
[Track3]        TrackCreateDate                 : 2020:01:01 10:00:00
[Track3]        TrackModifyDate                 : 2020:01:01 10:00:00
[Track3]        MediaCreateDate                 : 2020:01:01 10:00:00
[Track3]        MediaModifyDate                 : 2020:01:01 10:00:00
[Keys]          LocationDate                    : 2015:08:08 13:03:06+03:00
[IFD0]          ModifyDate                      : 2015:08:08 13:02:57
[ExifIFD]       DateTimeOriginal                : 2015:08:08 13:02:57
[ExifIFD]       CreateDate                      : 2015:08:08 13:02:57
[Canon]         TimeZone                        : +03:00
[Canon]         TimeZoneCity                    : Cairo
[Canon]         DaylightSavings                 : On
[ExifIFD]       SubSecTime                      : 55
[ExifIFD]       SubSecTimeOriginal              : 55
[ExifIFD]       SubSecTimeDigitized             : 55
[Composite]     SubSecCreateDate                : 2015:08:08 13:02:57.55
[Composite]     SubSecDateTimeOriginal          : 2015:08:08 13:02:57.55
[Composite]     SubSecModifyDate                : 2015:08:08 13:02:57.55

- Matti

StarGeek

Quote from: wywh on May 16, 2020, 02:51:07 PM
That tag needs a timezone because I noticed that Photos 5.0 datetime is scrambled and the year set to something like "177294" in mp4 and m4v if "Keys > CreationDate" or "UserData > DateTimeOriginal" is without timezone.

This is actually good news.  We've had a few previous cases where the Quicktime:DateTimeOriginal tag was causing problems with Photos.  If adding the time zone fixes the problem, it will help if it comes up again.

QuoteSome commands like "-AllDates<filename" create "UserData > DateTimeOriginal" without timezone. Is it best to use "-wm w" so no such unexpected tags are created? Or is it possible to force adding a timezone there?

You could tack the time zone on the end e.g. '-AllDates<$Filename -05:00', but that may too much manual work.  Either the -wm option as you suggest or just directly write the CreateDate/ModifyDate instead of AllDates.

QuoteBTW, why deleting "Keys > CreationDate" tag also deletes Composite > GPS* locations?

More info needed, like the exact command and tags.  Because my quick test here didn't change the GPS data.

QuoteA related question: In Canon 6D movies some apps seem to stubbornly get some datetimes from either "IFD0 > ModifyDate" or "ExifIFD > DateTimeOriginal". I have unsuccessfully tried to modify them the same as other datetimes or wipe them out. Any advice for that?

An EXIF block in a video file is non-standard, not that it doesn't stop camera companies from forcing it in.  Exiftool can't change this data.  I'm not sure if there is anything that can. 
* Did you read FAQ #3 and use the command listed there?
* Please use the Code button for exiftool code/output.
 
* Please include your OS, Exiftool version, and type of file you're processing (MP4, JPG, etc).

wywh

#5
Thanks,

'-AllDates<$filename +02:00' adds [UserData] DateTimeOriginal with a timezone so Photos.app 5.0 does not scramble m4v and mp4 dates. But with that command each timezone and DST must be manually set while QuickTimeUTC sets it automatically (back to 1970-0101). QuickTimeUTC seems to factor in even the movie's GPS when setting the timezone (is it possible to modify movie GPS tags -- I have a few where it is somehow way off?).

(BTW, iPhoto 5.0 seems to get datetime to pre-1970 movies from their file creation date which can be set by various macOS tools back to 1904-0101 at least until next reboot. iPhoto 5.0 imports [Keys] CreationDate correctly to even 0001-0101 (year 1) so it might be useful for very old movies.)

(Oh, forget the GPS deletion issue. I now noticed that there was also [Keys] GPS Coordinates, and I inadvertently deleted also it (and also [Composite] GPS *) by exiftool -m -P -overwrite_original_in_place -wm w -Keys:all= movie.mov when trying to delete only the [Keys] CreationDate.)

My old workflow had an error if a movie was from a different DST than the current DST: then "filename to metadata" followed in the other direction by "metadata to filename & filedate" would fail -+1 hour causing a danger to rename a movie -+ 1hour if it happens to be among images which behave correctly. Using QuickTimeUTC seems to fix that nicely.

Some of my applications display those EXIF block dates from Canon 6D movies. But luckily that seems to be mainly a cosmetic issue that can be ignored unless time shift is used in some applications.

I would like to update also the movie file's creation & modification datetimes to match the filename and other metadata. Is there a command that does not require installing macOS 10.15 Developer Tools?

Is there a more compact command to modify the QuickTime Track datetimes? That might not really be needed because none of my applications seem to care about them but it is easier to troubleshoot when all correct datetimes are the same.

The only remaining minor issue is how to attach the correct timezone and DST to the [Keys] CreationDate instead using a fixed timezone, although in practice that doesn't seem to matter. Now the command may change an existing correct timezone to that fixed timezone.

So my updated command is:

exiftool -m -P -overwrite_original_in_place -wm w -api QuickTimeUTC=1 "-AllDates<filename" "-Track*Date<filename" "-Media*Date<filename" '-Keys:CreationDate<$filename +02:00' movie.mov

- Matti

StarGeek

Quote from: wywh on May 17, 2020, 11:38:38 AMQuickTimeUTC seems to factor in even the movie's GPS when setting the timezone

The -api QuickTimeUTC option doesn't read the GPS settings.  It just corrects to and from local time.  It will use the time zone if it is part of the time stamp, otherwise it uses the local time zone of the computer.  Take note that you don't need to figure out if the local time zone was Daylight Savings or not.  The computer itself will supply the correct Standard/Daylight time adjustment

Quote(is it possible to modify movie GPS tags -- I have a few where it is somehow way off?).

Exiftool can write the GPSCoordinates tag that can be located in Keys, ItemList, and UserData.  It cannot change GPS data the may be embedded in the stream.

QuoteI would like to update also the movie file's creation & modification datetimes to match the filename and other metadata. Is there a command that does not require installing macOS 10.15 Developer Tools?

I don't use a Mac, so I don't know.
* Did you read FAQ #3 and use the command listed there?
* Please use the Code button for exiftool code/output.
 
* Please include your OS, Exiftool version, and type of file you're processing (MP4, JPG, etc).

Phil Harvey

QuoteI would like to update also the movie file's creation & modification datetimes to match the filename and other metadata. Is there a command that does not require installing macOS 10.15 Developer Tools?

Not that I know, or else I would have used it for ExifTool.

- Phil
...where DIR is the name of a directory/folder containing the images.  On Mac/Linux/PowerShell, use single quotes (') instead of double quotes (") around arguments containing a dollar sign ($).

wywh

#8
DeveloperTools took only a few minutes to install so also the file creation & modification datetimes could be set.

I tried to combine the following commands into one but for some reason the FileCreateDate could then only be set backwards although I tried to change the tags' order in the combined command. As a separate command it works also backwards (no problem with the FileModifyDate).

What also bothers me is that the fixed "[Keys] CreationDate" +02:00 timezone is incorrect for this June movie where it should be +03:00 (at least in this location...). It is possible to grab that correct DST timezone from the "[System] FileModifyDate" where it is correct (in January movies it is correctly set at +02:00). But how can I combine also it in one command that does it all?

So how can I combine these three commands into one (interim result shown after #2):

1. exiftool -m -P -overwrite_original_in_place -wm w -api QuickTimeUTC=1 "-AllDates<filename" "-Track*Date<filename" "-Media*Date<filename" '-Keys:CreationDate<$filename +02:00' 2020-0601-1200-00_iphone4s_ios9.3.2.mov

2. exiftool -m -P -overwrite_original_in_place -wm w "-FileCreateDate<filename" "-FileModifyDate<filename" 2020-0601-1200-00_iphone4s_ios9.3.2.mov

exiftool -a -G1 -s -time:all 2020-0601-1200-00_iphone4s_ios9.3.2.mov
[System]        FileModifyDate                  : 2020:06:01 12:00:00+03:00
[System]        FileAccessDate                  : 2020:06:01 12:00:00+03:00
[System]        FileInodeChangeDate             : 2020:05:18 19:57:06+03:00
[QuickTime]     CreateDate                      : 2020:06:01 09:00:00
[QuickTime]     ModifyDate                      : 2020:06:01 09:00:00
[Track1]        TrackCreateDate                 : 2020:06:01 09:00:00
[Track1]        TrackModifyDate                 : 2020:06:01 09:00:00
[Track1]        MediaCreateDate                 : 2020:06:01 09:00:00
[Track1]        MediaModifyDate                 : 2020:06:01 09:00:00
[Track2]        TrackCreateDate                 : 2020:06:01 09:00:00
[Track2]        TrackModifyDate                 : 2020:06:01 09:00:00
[Track2]        MediaCreateDate                 : 2020:06:01 09:00:00
[Track2]        MediaModifyDate                 : 2020:06:01 09:00:00
[Track3]        TrackCreateDate                 : 2020:06:01 09:00:00
[Track3]        TrackModifyDate                 : 2020:06:01 09:00:00
[Track3]        MediaCreateDate                 : 2020:06:01 09:00:00
[Track3]        MediaModifyDate                 : 2020:06:01 09:00:00
[Track4]        TrackCreateDate                 : 2020:06:01 09:00:00
[Track4]        TrackModifyDate                 : 2020:06:01 09:00:00
[Track4]        MediaCreateDate                 : 2020:06:01 09:00:00
[Track4]        MediaModifyDate                 : 2020:06:01 09:00:00
[Keys]          CreationDate                    : 2020:06:01 12:00:00+02:00

3. exiftool -m -P -overwrite_original_in_place -wm w "-Keys:CreationDate<FileModifyDate" 2020-0601-1200-00_iphone4s_ios9.3.2.mov

[Keys]          CreationDate                    : 2020:06:01 12:00:00+03:00

- Matti

Phil Harvey

Hi Matti,

Quote from: wywh on May 18, 2020, 01:58:41 PM
I tried to combine the following commands into one but for some reason the FileCreateDate could then only be set backwards

I haven't looked at your commands yet, but I have noticed that MacOS seems to force the FileCreateDate to be before FileModifyDate, which can produce odd effects.

QuoteWhat also bothers me is that the fixed "[Keys] CreationDate" +02:00 timezone is incorrect

The time zone for this is stored in the file.  You can use the -v3 option to see the actual binary value.

I'll have to take a look at your commands when I get a chance and answer the rest of  your questions.

- Phil
...where DIR is the name of a directory/folder containing the images.  On Mac/Linux/PowerShell, use single quotes (') instead of double quotes (") around arguments containing a dollar sign ($).

wywh

My current plan to grab the date and timezone from the FileModifyDate to the "[Keys] CreationDate" has a flaw. The original timezone should be mostly correct and I wouldn't want to destroy it from the vacation movies in different timezones by inserting the current local timezone. But that original correct timezone must then be appended to the modified date with the correct DST setting for that date. I'll look what -v3 can do.

That said, I haven't yet noticed any ill effects using a wrong timezone in the "[Keys] CreationDate". But I plan to correct the movie metadata in all my old movies and I would like to do it right. The filename is my golden standard for movie dates and with hundreds of movies it is tempting to use that to correct the metadata accordingly. Doing it manually one or several movies at a time is time consuming and error-prone.

wywh

#11
Oh, and another flaw in my previous plan is that if mp4 or m4v already have "[UserData] DateTimeOriginal"+02:00 with a timezone, then "-AllDates<filename" strips the timecode off from it and Catalina Photos.app 5.0 displays scrambled date (mov seems to be immune).

This could be a Catalina Photos.app 5.0 bug that might be corrected. But anyway:

That could be bypassed by substituting the simple "-AllDates<filename" that strips the timezone with a more clumsy:

"-CreateDate<filename" "-ModifyDate<filename" '-DateTimeOriginal<$filename +02:00'

So those commands should be:

1. exiftool -m -P -overwrite_original_in_place -wm w -api QuickTimeUTC=1 "-CreateDate<filename" "-ModifyDate<filename" "-Track*Date<filename" "-Media*Date<filename" '-DateTimeOriginal<$filename +02:00' '-Keys:CreationDate<$filename +02:00' 2020-0601-1200-00_iphone4s_ios9.3.2.mov

2. exiftool -m -P -overwrite_original_in_place -wm w "-FileCreateDate<filename" "-FileModifyDate<filename" 2020-0601-1200-00_iphone4s_ios9.3.2.mov

3. exiftool -m -P -overwrite_original_in_place -wm w "-DateTimeOriginal<FileModifyDate" "-Keys:CreationDate<FileModifyDate" 2020-0601-1200-00_iphone4s_ios9.3.2.mov

BTW I did a quick test and it seems the Photos.app 5.0 grabs the date in the following order, and it displays the time from a January (no DST) movie in my location at the moment when DST is ON the following way (timezone display can be added as a macOS Language & Region > Medium custom preference):

1. [Keys] CreationDate. Time 12:00:00+02:00 displayed as 12.00.00+02:00. If timezone is omitted in m4v and mp4 the date is scrambled.

2. [UserData] DateTimeOriginal. Time 12:00:00+02:00 displayed as 12.00.00+02:00. If timezone is omitted in m4v and mp4 the date is scrambled.

3. [QuickTime] CreateDate. Time set with "QuickTimeUTC=1" is set as 10:00:00 and displayed as 12.00.00+02:00 (in DST movie set as 09:00:00 and displayed as 12.00.00+03:00). "QuickTimeUTC=0" sets it as 12:00:00 and displayed as 14.00.00+02:00 (in DST movie set as 12:00:00 and displayed as 15.00.00+03:00).

4. [System] FileCreateDate. Time 12:00:00+02:00 displayed as 12.00.00+02:00.

So if there is no other metadata in the movie, as a last resort Photos.app 5.0 gets it from the file creation date. My old movies didn't seem to have XMP dates so I didn't test them.

wywh

#12
One more update to the commands that edit metadata in my test movies almost correct. The remaining flaw is that the computer's current timezone is used for "[Keys] CreationDate" and "[UserData] DateTimeOriginal" and the original mostly correct timezones are destroyed. So vacation movies in different timezones get a wrong timezone. I haven't found a way to combine these three commands.

First filename to [QuickTime] tags (I didn't use shortcut "-AllDates<filename" because it creates "UserData > DateTimeOriginal" without timezone which scrambles Catalina's Photos.app 5.0 dates):

1. exiftool -m -P -overwrite_original_in_place -wm w -api QuickTimeUTC=1 "-CreateDate<filename" "-ModifyDate<filename" "-Track*Date<filename" "-Media*Date<filename" movies.*

Then filename to file creation & modification date. For some reason this command seems to work only on its own. If it is combined with the previous command, then FileCreateDate moves only forwards in time (Apple's Developer Tools not needed for the backwards-only shift):

2. exiftool -m -P -overwrite_original_in_place -wm w "-FileCreateDate<filename" "-FileModifyDate<filename" movies.*

And finally grab the correct datetime and DST for the winter & summer movies' dates to "[Keys] CreationDate" and "[UserData] DateTimeOriginal" tags. As a flaw the original mostly correct timezones are destroyed. So vacation movies in different timezones get a wrong timezone:

3. exiftool -m -P -overwrite_original_in_place -wm w "-DateTimeOriginal<FileModifyDate" "-Keys:CreationDate<FileModifyDate" "-UserData:DateTimeOriginal<FileModifyDate" movies.*

Update to the Catalina's Photos.app 5.0 date algorithm test in my previous message: Photos seems to grab the date in the following order for m4v and mp4, and it displays the time the following way when the computer is set to +02:00 timezone. Photos.app can display the timezone when it is added as a custom preference to macOS Language & Region > Advanced... > Times > drag the Time Zone to the Medium length format:

1. [Keys] CreationDate. Time 12:00:00+02:00 displayed as 12.00.00+02:00. DST time 12:00:00+03:00 displayed as 12.00.00+03:00. If timezone is omitted in m4v and mp4 the date is scrambled.

2. [UserData] DateTimeOriginal. Time 12:00:00+02:00 displayed as 12.00.00+02:00. DST time 12:00:00+03:00 displayed as 12.00.00+03:00. If timezone is omitted in m4v and mp4 the date is scrambled. mov files seem to ignore this tag.

3. [QuickTime] CreateDate. Time set with "QuickTimeUTC=1" is set as 10:00:00 and displayed as 12.00.00+02:00. DST movie set as 09:00:00 and displayed as 12.00.00+03:00. If the computer's timezone is changed to -02:00, then displayed as 10.00.00Z (i.e. 10.00.00+00:00) and a DST movie displayed as 10.00.00+01:00. Photos.app does not change the displayed time if the computer's timezone is changed after the movie is imported.

Time set with "QuickTimeUTC=0" is set as 12:00:00 and displayed as 14.00.00+02:00. DST movie set as 12:00:00 and displayed as 15.00.00+03:00.

4. [System] FileCreateDate. Time 12:00:00+02:00 displayed as 12.00.00+02:00. DST Time 12:00:00+03:00 displayed as 12.00.00+03:00.

So if there is no other metadata in the movie, as a last resort Photos.app 5.0 gets it from the file creation date.

Photos.app 5.0 seems to display GPS timezone, if available.

Catalina Photos.app 5.0 seems to ignore these tags:
[XMP-exif]      DateTimeOriginal                : 2020:01:01 12:00:00
[XMP-xmp]       CreateDate                      : 2020:01:01 12:00:00
[XMP-xmp]       ModifyDate                      : 2020:01:01 12:00:00

- Matti

wywh

#13
The following commands seem to set the metadata in my test movies almost as desired when the filename is used as a golden standard. DST differences are automatically taken care of with "-api QuickTimeUTC=1".

A remaining fly in the ointment is that vacation movies in different timezones get my computer's timezone, but I think that is OK because then in Photos.app 12:00 in filename always corresponds 12:00. Based on different [QuickTime], [Keys], [Userdata] or [GPS] tags there is an occasional 00:00-01:00-02:00-03:00 timezone & DST correction that can be ignored (by default Photos.app does not even show timezones although they affect sorting).

I tested setting the computer to the vacation timezone while running the commands but then Photos.app confusingly (but correctly) showed what the time was at home when the movie was shot. I.e. a 12:00 [QuickTime]-only tagged movie in London in the winter is now shown taken at 14:00+02:00 while other movies with extra [Keys], [Userdata] or [GPS] datetime tags and jpg images are shown at 12:00Z (and summer movies shown as 14:00+03:00 and 12:00+01:00). It gets even more confusing with movies from more distant timezones like Beijing when the displayed time jumps between 06:00 and 12:00 on same scenes depending which tag Photos.app happens to use.

No matter what timezone I set the computer, the varying timezone display format from different tags mangles Photos.app sorting (+02:00 is sorted before an occasional Z etc) so I guess vacation movies must be manually adjusted if needed anyway. Photos.app does sort such vacation movies correctly when the timezone is changed also when importing but that is clumsy. I hope Photos.app could be updated to use various sorting options but I am not holding my breath.

So in the following commands the computer's current timezone is used for "[Keys] CreationDate" and "[UserData] DateTimeOriginal" and the original mostly correct timezones are destroyed. Maybe that info could be preserved in some [XMP] tag? But usually the timezone is readily apparent from the movie content so this is not a big deal.

So my current plan is the following. Please correct me if necessary:

1. First filename to [QuickTime] tags (this works for 1970-0101-0000-00 UTC or later for QuickTime. Surprisingly it seems to work to about 1904-0101-0200-00 or later obviously with the aid of "-api QuickTimeUTC=1", even Photos.app 5.0 reads that date OK from a mp4 or m4v movie. I didn't use shortcut "-AllDates<filename" because it creates "[UserData] DateTimeOriginal" without timezone which scrambles Catalina's Photos.app 5.0 dates):

exiftool -m -P -overwrite_original_in_place -wm w -api QuickTimeUTC=1 "-CreateDate<filename" "-ModifyDate<filename" "-Track*Date<filename" "-Media*Date<filename" movies.*

2. Then filename to file creation & modification date (this works for 1677-0921-0152-33 or later in macOS 10.15. For some reason this command seems to work only on its own. If it is combined with the previous command, then FileCreateDate moves only forwards in time. SetFile from Apple's Xcode Command Line Tools can be installed with the command "xcode-select --install". SetFile is not needed for backwards-only shift):

exiftool -m -P -overwrite_original_in_place -wm w "-FileCreateDate<filename" "-FileModifyDate<filename" movies.*

3. And finally grab the correct datetime and DST for the winter & summer movies' dates to "[Keys] CreationDate" and "[UserData] DateTimeOriginal" tags if they are already present (this works for 1677-0921-0152-33 or later in macOS 10.15). As a minor flaw the original mostly correct timezones are destroyed in those tags so vacation movies in different timezones get a wrong timezone:

exiftool -m -P -overwrite_original_in_place -wm w "-Keys:CreationDate<FileModifyDate" "-UserData:DateTimeOriginal<FileModifyDate" movies.*

Commands 1-3 together for 1677-0921-0152-33 or later movies:

exiftool -m -P -overwrite_original_in_place -wm w -api QuickTimeUTC=1 "-CreateDate<filename" "-ModifyDate<filename" "-Track*Date<filename" "-Media*Date<filename" -execute -m -P -overwrite_original_in_place -wm w "-FileCreateDate<filename" "-FileModifyDate<filename" -execute -m -P -overwrite_original_in_place -wm w "-Keys:CreationDate<FileModifyDate" "-UserData:DateTimeOriginal<FileModifyDate" -common_args movies.*

BTW, a similar command also works for 1970-0101-0000-00 UTC or later movies because it relies on QuickTime tags (surprisingly it seems to work to about 1904-0101-0200-00 or later obviously with the aid of "-api QuickTimeUTC=1", even Photos.app 5.0 reads that date OK from a mp4 or m4v movie):

exiftool -m -P -overwrite_original_in_place -wm w -api QuickTimeUTC=1 "-CreateDate<filename" "-ModifyDate<filename" "-Track*Date<filename" "-Media*Date<filename" -execute -m -P -overwrite_original_in_place -wm w -api QuickTimeUTC=1 "-Keys:CreationDate<QuickTime:CreateDate" "-UserData:DateTimeOriginal<QuickTime:CreateDate" -execute -m -P -overwrite_original_in_place -wm w "-FileCreateDate<filename" "-FileModifyDate<filename" -common_args movies.*

With separate commands [Keys] and maybe also [UserData] tags can be  set to year 0001 or later for really old movies so they sort correctly in Photos.app (I guess [UserData] can be left out if it is not already present):

exiftool -m -P -overwrite_original_in_place "-Keys:CreationDate=0001:01:01 00:00:00+02:00" "-UserData:DateTimeOriginal=0001:01:01 00:00:00+02:00" movie.mov

Catalina's Photos.app 5.0 seems to grab the date in the following order for m4v and mp4 (mov differs slightly), and it displays the time the following way when the computer is set to +02:00 timezone. Photos.app can display the timezone when it is added as a custom preference to macOS Language & Region > Advanced... > Times > drag the Time Zone to the Medium length format:

1. [Keys] CreationDate. Time 12:00:00+02:00 displayed as 12.00.00+02:00. DST time 12:00:00+03:00 displayed as 12.00.00+03:00. If timezone is omitted in m4v and mp4 the date is scrambled.

2. [UserData] DateTimeOriginal. Time 12:00:00+02:00 displayed as 12.00.00+02:00. DST time 12:00:00+03:00 displayed as 12.00.00+03:00. If timezone is omitted in m4v and mp4 the date is scrambled. mov files seem to ignore this tag.

3. [QuickTime] CreateDate. Time set with "QuickTimeUTC=1" is set as 10:00:00 and displayed as 12.00.00+02:00. DST movie set as 09:00:00 and displayed as 12.00.00+03:00. If the computer's timezone is changed to -02:00, then displayed as 10.00.00Z (i.e. 10.00.00+00:00) and a DST movie displayed as 10.00.00+01:00. Photos.app does not change the displayed time if the computer's timezone is changed after the movie is imported.

Time set with "QuickTimeUTC=0" is set as 12:00:00 and displayed as 14.00.00+02:00. DST movie set as 12:00:00 and displayed as 15.00.00+03:00.

4. [System] FileCreateDate. Time 12:00:00+02:00 displayed as 12.00.00+02:00. DST Time 12:00:00+03:00 displayed as 12.00.00+03:00.

So if there is no other metadata in the movie, as a last resort Photos.app 5.0 gets it from the file creation date.

Photos.app 5.0 seems to display GPS timezone, if available.

Catalina Photos.app 5.0 seems to ignore these tags:
[XMP-exif]      DateTimeOriginal                : 2020:01:01 12:00:00
[XMP-xmp]       CreateDate                      : 2020:01:01 12:00:00
[XMP-xmp]       ModifyDate                      : 2020:01:01 12:00:00

BTW, where does the computer query the DST info? Since 1996, European Summer Time has been observed from the last Sunday in March to the last Sunday in October at UTC 01:00. Starting in 2007, most of the United States and Canada observed DST from the second Sunday in March to the first Sunday in November. The beginning and ending dates are roughly reversed between the northern and southern hemispheres because spring and autumn are displaced six months. For example, mainland Chile observes DST from the second Saturday in October to the second Saturday in March. Over a year ago the EU agreed to stop DST but that decision seems to have been buried in bureaucracy. If in doubt, the historical DST can be checked here:

https://www.timeanddate.com/time/change/

- Matti

wywh

Quote from: Phil Harvey on May 15, 2020, 08:12:35 AM

Quote from: wywh on May 14, 2020, 01:40:20 PM
Is there an option to set the DST timezone according to the date for [CreationDate] in a similar way like "exiftool -api QuickTimeUTC=1" seems to do automatically?

No.  This tag is stored as text with time zone, so that time zone is what you get.

I might not have explained the goal properly. Anyway, I noticed it is possible to use "-api QuickTimeUTC=1" to grab the timezone with DST correction to [Keys]. Without that -api the timezone is omitted:

exiftool -a -G1 -s -api QuickTimeUTC=0 -time:all movie.mov
[QuickTime]     CreateDate                      : 2020:01:01 10:00:00


But the timezone can be revealed and grabbed to another tag by setting the -api QuickTimeUTC=1:

exiftool -m -P -overwrite_original_in_place -api QuickTimeUTC=1 "-Keys:CreationDate<QuickTime:CreateDate" movie.mov
exiftool -a -G1 -s -api QuickTimeUTC=0 -time:all movie.mov
[QuickTime]     CreateDate                      : 2020:01:01 10:00:00
[Keys]          CreationDate                    : 2020:01:01 12:00:00+02:00


I now use this for all movie date queries because this is what also Photos.app displays:

exiftool -a -G1 -s -api QuickTimeUTC=1 -time:all movie.mov
[QuickTime]     CreateDate                      : 2020:01:01 12:00:00+02:00


So the command works for 1970-0101-0000-00 UTC or later movies because it relies on QuickTime tags (surprisingly it seems to work to about (*) 1904-0101-0200-00 or later obviously with the aid of "-api QuickTimeUTC=1" ... (*) we had some local time adjustments in 1921 which obviously cause weird 20 min 10,9 sec or up to 2 hour time effects before that):

exiftool -m -P -overwrite_original_in_place -wm w -api QuickTimeUTC=1 "-CreateDate<filename" "-ModifyDate<filename" "-Track*Date<filename" "-Media*Date<filename" -execute -m -P -overwrite_original_in_place -wm w -api QuickTimeUTC=1 "-Keys:CreationDate<QuickTime:CreateDate" "-UserData:DateTimeOriginal<QuickTime:CreateDate" -execute -m -P -overwrite_original_in_place -wm w "-FileCreateDate<filename" "-FileModifyDate<filename" -common_args movies.*

But this similar command is even better because it works for year 1677-0921-0152-33 or later (*) movies on macOS. (The command does not add any new tags. If you want to add only [Keys] and not [UserData], then delete "-wm w" switch and [UserData] part from the third part of the command). (* Yes, there are no real movies that old but I like to put metadata dates to old paintings, movies depicting old era etc, if possible. Sadly Google Photos accepts EXIF dates only after 01.01.1902).

I hope the command is as compact and fast as possible because I intend to use it for 300 GB of several hundred old movies:

exiftool -m -P -overwrite_original_in_place -wm w -api QuickTimeUTC=1 "-CreateDate<filename" "-ModifyDate<filename" "-Track*Date<filename" "-Media*Date<filename" -execute -m -P -overwrite_original_in_place -wm w "-FileCreateDate<filename" "-FileModifyDate<filename" -execute -m -P -overwrite_original_in_place -wm w "-Keys:CreationDate<FileModifyDate" "-UserData:DateTimeOriginal<FileModifyDate" -common_args movies.*

With separate commands [Keys] and maybe also [UserData] tags can be  set to year 0001 or later for really old movies so they sort correctly in Photos.app ([UserData] can be left out if it is not already present):

exiftool -m -P -overwrite_original_in_place "-Keys:CreationDate=0001:01:01 00:00:00+02:00" "-UserData:DateTimeOriginal=0001:01:01 00:00:00+02:00" movie.mov

- Matti