When adjusting time zone and DST to Keys:CreationDate (and maybe also to the less important UserData:DateTimeOriginal), does exiftool grab them from the computer's time zone and DST from a net database?
So is it best to leave time zones off and let exiftool and the users's computer's time zone setting take care what to fill there with a command like:
exiftool -m -P -overwrite_original_in_place -api QuickTimeUTC=1 -api LargeFileSupport=1 -AllDates='2001:06:01 12:00:00' '-Track*Date=2001:06:01 12:00:00' '-Media*Date=2001:06:01 12:00:00' -Keys:CreationDate='2001:06:01 12:00:00' -wm w movie.mp4
exiftool -a -G1 -s -api QuickTimeUTC=1 -Time:All movie.mp4
[System] FileModifyDate : 2021:02:16 16:19:31+02:00
[System] FileAccessDate : 2022:11:28 11:42:50+02:00
[System] FileInodeChangeDate : 2023:03:08 19:04:30+02:00
[QuickTime] CreateDate : 2001:06:01 12:00:00+03:00
[QuickTime] ModifyDate : 2001:06:01 12:00:00+03:00
[Track1] TrackCreateDate : 2001:06:01 12:00:00+03:00
[Track1] TrackModifyDate : 2001:06:01 12:00:00+03:00
[Track1] MediaCreateDate : 2001:06:01 12:00:00+03:00
[Track1] MediaModifyDate : 2001:06:01 12:00:00+03:00
[Track2] TrackCreateDate : 2001:06:01 12:00:00+03:00
[Track2] TrackModifyDate : 2001:06:01 12:00:00+03:00
[Track2] MediaCreateDate : 2001:06:01 12:00:00+03:00
[Track2] MediaModifyDate : 2001:06:01 12:00:00+03:00
[Keys] CreationDate : 2001:06:01 12:00:00+03:00
[UserData] DateTimeOriginal : 2001:06:01 12:00:00+03:00
I guess that command could be shortedned with wildcards.
AFAIK newish exiftool versions force timezone to Keys:CreationDate and UserData:DateTimeOriginal because otherwise some older versions of Apple's Photos.app display completely erroneous years like '5828963':
"Dec. 24, 2020 - Version 12.13
Add time zone automatically to most string-based QuickTime date/time tags when writing unless the PrintConv option is disabled"
https://exiftool.org/ancient_history.html
...with that -n I can force exiftool to leave time zone OFF:
exiftool -m -P -n -overwrite_original_in_place -api QuickTimeUTC=1 -api LargeFileSupport=1 -AllDates='2001:06:01 12:00:00' '-Track*Date=2001:06:01 12:00:00' '-Media*Date=2001:06:01 12:00:00' -Keys:CreationDate='2001:06:01 12:00:00' -wm w movie.mp4
exiftool -a -G1 -s -api QuickTimeUTC=1 -Time:All movie.mp4
[QuickTime] CreateDate : 2001:06:01 12:00:00+03:00
[Keys] CreationDate : 2001:06:01 12:00:00
...then macOS 13.2 Ventura Photos.app no longer scrambles the year like earlier macOS versions do. But it then displays that time as 15:00.
- Matti
Hi Matti,
Quote from: wywh on March 08, 2023, 12:13:09 PMWhen adjusting time zone and DST to Keys:CreationDate (and maybe also to the less important UserData:DateTimeOriginal), does exiftool grab them from the computer's time zone and DST from a net database?
ExifTool never makes a network connection. Your system has a time zone setting that ExifTool can access.
QuoteAFAIK newish exiftool versions force timezone to Keys:CreationDate and UserData:DateTimeOriginal because otherwise some older versions of Apple's Photos.app display completely erroneous years like '5828963':
You're saying that Apple Photos displays the incorrect year if the time zone used on either of these two tags?
Quoteexiftool -a -G1 -s -api QuickTimeUTC=1 -Time:All movie.mp4
[QuickTime] CreateDate : 2001:06:01 12:00:00+03:00
[Keys] CreationDate : 2001:06:01 12:00:00[/code]
...then macOS 13.2 Ventura Photos.app no longer scrambles the year like earlier macOS versions do. But it then displays that time as 15:00.
I don't understand this. Presumably Apple Photos displays the date/time from iPhone videos correctly, and as far as I can tell these are written extactly the same as done by ExifTool:
> exiftool a.mov -quicktime:creationdate=now
1 image files updated
> exiftool a.mov ../pics/Apple* -ext mov -ext mp4 -v3 | grep -Ei '(====| CreationDate)'
======== a.mov
| | | Added ItemList Tag 1.7 = (mdta) creationdate
| | | CreationDate = 2023-03-08T12:26:12-0500
======== ../pics/Apple_iPhone.mov
| | | Added ItemList Tag 2.2 = (mdta) creationdate
| | | CreationDate-heb-IL = 2010-10-06T17:21:55+0200
======== ../pics/Apple_iPhone3GS.mov
======== ../pics/Apple_iPhone4.mov
| | | Added ItemList Tag 2.2 = (mdta) creationdate
| | | CreationDate-und-US = 2010-06-25T17:50:16-0400
======== ../pics/Apple_iPhone4S-no_gps.mov
| | | Added ItemList Tag 2.2 = (mdta) creationdate
| | | CreationDate-fra-FR = 2014-02-23T23:36:34+0100
======== ../pics/Apple_iPhone4S.mov
| | | Added ItemList Tag 2.2 = (mdta) creationdate
| | | CreationDate-fra-FR = 2014-02-23T23:34:30+0100
======== ../pics/Apple_iPhone5c.mov
| | | Added ItemList Tag 2.2 = (mdta) creationdate
| | | CreationDate-und-US = 2014-03-29T13:27:04-0500
======== ../pics/Apple_iPhone6Plus.mov
| | | Added ItemList Tag 2.5 = (mdta) creationdate
| | | CreationDate = 2014-11-11T14:21:25+0000
======== ../pics/Apple_iPhoneXR.mov
| | | Added ItemList Tag 1.5 = (mdta) creationdate
| | | CreationDate = 2018-10-28T15:54:29+0000
======== ../pics/Apple_iPhoneXS.mov
| | | Added ItemList Tag 1.5 = (mdta) creationdate
| | | CreationDate = 2018-10-10T16:20:22+0100
======== ../pics/Apple_iPodNano_gen5.mov- Phil
Quote from: Phil Harvey on March 08, 2023, 12:28:33 PMExifTool never makes a network connection. Your system has a time zone setting that ExifTool can access.
Yes, and I think the computer OS
somehow knows the time zone and when DST was in effect in
that location. So I guess the user's computer checks the time zone, DST etc via some server?
Quote>> AFAIK newish exiftool versions force timezone to Keys:CreationDate and UserData:DateTimeOriginal because otherwise some older versions of Apple's Photos.app display completely erroneous years like '5828963'
> You're saying that Apple Photos displays the incorrect year if the time zone used on either of these two tags?
No, the opposite. In macOS 12 Monterey and earlier, Photos scrambled the year if there was no time zone in Keys:CreationDate or the less important UserData:DateTimeOriginal.
macOS 13 Ventura Photos no longer scrambles the time-zone-less Keys:CreationDate but displays it as UTC.
exiftool does all this OK but I am figuring out how the current macOS handles UTC and local date variations in movies so I can nag GC author to set them correctly once and for all (for now) ???
- Matti
Quote from: wywh on March 08, 2023, 01:20:19 PMYes, and I think the computer OS somehow knows the time zone and when DST was in effect in that location. So I guess the user's computer checks the time zone, DST etc via some server?
I believe this is built into the operating system's date/time libraries. Tom Scott has a great video about computers and time zones (https://www.youtube.com/watch?v=-5wpm-gesOY).
Quote from: StarGeek on March 09, 2023, 10:05:34 AMI believe this is built into the operating system's date/time libraries
So when it is
baked-in to OS libraries ... it works around the world and different DST conventions even off-line ... until it breaks and the OS is updated, right?
I was asking this because I am pestering GraphicConverter author to update movie (.mp4, .m4v and .mov) metadata to better handle dates (UTC and local time mixed together, proprietary Canon thumbnail dates...), GPS with altitudes, as well as some other experimental Keys metadata (Description with linebreaks and tabs, Author/Writer, DisplayName/Headline, Title, Keywords). So that they work with the latest macOS and iOS apps.
Leaving time zone off from the date command resolved an issue with daylight savings time discrepancies. So something like this seems to work fine when exiftool automatically decides what time zone and DST should be applied
for that computer location for UTC and local time with a command like:
exiftool -m -P -overwrite_original_in_place -api QuickTimeUTC=1 -api LargeFileSupport=1 -AllDates='2001:06:01 12:00:00' '-Track*Date=2001:06:01 12:00:00' '-Media*Date=2001:06:01 12:00:00' -Keys:CreationDate='2001:06:01 12:00:00' -wm w movie.mp4And for that other metadata as well (I now decided to omit Keys:DisplayName from my movies because Keys:Title is basically the same as GC GUI for the corresponding .jpg):
exiftool -m -P -overwrite_original_in_place -api LargeFileSupport=1 -Keys:GPSCoordinates='-36.6101, -66.91515, 119.92' -Keys:Title='Title' -Keys:DisplayName='DisplayName' -Keys:Author='Author' -Keys:Description='Description' -Keys:Keywords='Keyword 1,Keyword 2' movie.mp4Insert linebreaks and tabs with a command like:
exiftool -ec -overwrite_original_in_place -api LargeFileSupport=1 -Keys:Description='One line break:\nTwo line breaks:\n\nUmlauts åäöÅÄÖ and a dot .\nTabs\tbetween\twords' movie.mp4The recent GC 12 beta gc12_build6029 was already pretty good in macOS 13 Ventura QuickTime Player and Photos.app.
https://www.lemkesoft.org/beta.html
- Matti
Quote from: wywh on March 09, 2023, 11:07:28 AMQuote from: StarGeek on March 09, 2023, 10:05:34 AMI believe this is built into the operating system's date/time libraries
So when it is baked-in to OS libraries ... it works around the world and different DST conventions even off-line ... until it breaks and the OS is updated, right?
Except such things are usually known about and patched months in advance, so there never is an actual break. Except in Libya in 2013 (see above Tom Scott video).