Determine Time Zone automatically?

[babola]

Hi, I'm new to ExifTool, so if I'm missing something obvious, I apologize in advance.

The situation: my prior cameras (Panasonic Lumix models) had built-in GPS. But my new camera (Canon PowerShot SX740 HS) does not. So I went to Italy knowing I'd need to GPS track all my movements while shooting photographs so that I could post-process the photos after I got home in order to add GPS information. I used the myTracks iOS app on my phone to gather the GPS data and create gpx files. Now, back home, I've copied all gpx and jpg files from the phone and camera to my Mac computer and installed ExifTool.

I have read the ExifTool documentation; in particular, this page: https://exiftool.org/geotag.html

What I don't understand is: Why can't ExifTool automatically determine the TimeZone, and sync the photos with a gpx track? This *should* work:

$ exiftool -geotag=../gpx_files/CDG\ 2022-05-13\ 10_49_03.gpx  ./IMG_0115.JPG
Warning: Time is too far beyond track in File:Geotime (ValueConvInv) - ./IMG_0115.JPG
Warning: No writable tags set from ./IMG_0115.JPG
    0 image files updated
    1 image files unchanged


Ok, let's add the -v2 command line option:

$ exiftool -v2 -geotag=../gpx_files/CDG\ 2022-05-13\ 10_49_03.gpx  ./IMG_0115.JPG
Argument "-Geotime<DateTimeOriginal#" is assumed
Loaded 318 points from XML-format GPS track log file '../gpx_files/CDG 2022-05-13 10_49_03.gpx'
  GPS track start: 2022:05:13 08:49:03.002 UTC
  GPS track end:   2022:05:13 09:39:21.499 UTC
Writing File:Geotag
======== ./IMG_0115.JPG
Setting new values from ./IMG_0115.JPG
  Geotime value:   2022:05:13 18:20:06.000 UTC (local timezone is -07:00)
Warning: Time is too far beyond track in File:Geotime (ValueConvInv) - ./IMG_0115.JPG
Warning: No writable tags set from ./IMG_0115.JPG
Nothing changed in ./IMG_0115.JPG
    0 image files updated
    1 image files unchanged


So we can see that the GPS track has timestamps in UTC, as always. And here are all the date/time stamps in the photo file:

$ exiftool -s -time:all  ./IMG_0115.JPG
FileModifyDate                  : 2022:05:13 11:20:06-07:00
FileAccessDate                  : 2022:05:30 15:53:48-07:00
FileInodeChangeDate             : 2022:05:29 18:55:20-07:00
ModifyDate                      : 2022:05:13 11:20:06
DateTimeOriginal                : 2022:05:13 11:20:06
CreateDate                      : 2022:05:13 11:20:06
OffsetTime                      : +02:00
OffsetTimeOriginal              : +02:00
OffsetTimeDigitized             : +02:00
TimeZone                        : +02:00
TimeZoneCity                    : Paris
DaylightSavings                 : On
SubSecTime                      : 64
SubSecTimeOriginal              : 64
SubSecTimeDigitized             : 64
SubSecCreateDate                : 2022:05:13 11:20:06.64+02:00
SubSecDateTimeOriginal          : 2022:05:13 11:20:06.64+02:00
SubSecModifyDate                : 2022:05:13 11:20:06.64+02:00


Here we can see that the various OffsetTime* values are all +02:00. Not only that, the TimeZone is also +02:00. So, in my humble opinion, ExifTool should be able to say "Aha, this photo is in the +02:00 time zone, so I need to subtract 2 hours from all timestamps (that don't specify time zone) in order to sync to the UTC timestamps in the gpx track".

But no. After a good deal of trial and error, I discover that I have to do this:

$ exiftool -geotag=../gpx_files/CDG\ 2022-05-13\ 10_49_03.gpx  -geosync=-09:00:00 ./IMG_0115.JPG
    1 image files updated


In other words, I have to adjust for my *current* time zone here in California!  Why in the world should I have to do that?  This is FAR from intuitive. If the gpx track timestamps are always stored as UTC, and the camera is correctly set to the time zone where the photos are being shot, then it should be *irrelevant* where in the world I happen to be located when I choose to sync the photos and gpx data.

Even worse: While I was traveling, I was meticulous about keeping the camera's time zone set correctly as I moved from one time zone to another. Given that ExifTool supports multiple gpx files in a single invocation, I should be able to do this to geotag all my photos, no matter where they were shot:

$ exiftool -geotag=gpx_file_1.gpx  -geotag=gpx_file_2.gpx ... -geotag=gpx_file_n.gpx    /Folder_with_hundreds_of_photos


But given that I have to specify "-geosync=-09:00:00" for photos in the "+02:00" time zone, and then "-geosync=-08:00:00" for photos in the "+01:00" time zone, etc., I therefore have to use multiple ExifTool invocations. And I have to figure out which photos were taken in which time zone, and separate them into separate folders, or whatever, to make this work.

Do you see my problem? As I said before, I could be (probably am) missing something obvious. If there's a way to tell ExifTool: "Use the time zone embedded in the EXIF data (and IGNORE my CURRENT time zone)", that would be really cool.

Thanks,
Barry

[StarGeek]

What I don't understand is: Why can't ExifTool automatically determine the TimeZone, and sync the photos with a gpx track?

Because there often isn't any source other than the computer's system time to determine the time zone.

Here we can see that the various OffsetTime* values are all +02:00. Not only that, the TimeZone is also +02:00. So, in my humble opinion, ExifTool should be able to say "Aha, this photo is in the +02:00 time zone, so I need to subtract 2 hours from all timestamps (that don't specify time zone) in order to sync to the UTC timestamps in the gpx track".

The thing is, the various OffsetTime* tags did not exist when exiftool was written.  They are a pretty recent addition to the EXIF standard, having been added in July 2016.  And cameras have only recently including those tags, only in about the past two years.  And if you use the command in FAQ #3, you'll see that the TimeZone tag is a camera specific MakerNotes tag, something that can't be depended upon being in every file.

Do you see my problem? As I said before, I could be (probably am) missing something obvious. If there's a way to tell ExifTool: "Use the time zone embedded in the EXIF data (and IGNORE my CURRENT time zone)", that would be really cool.

You should have looked at the docs on the -geotag option and the Geotag page examples.  The doc page gives an example of
exiftool -geotag trk.log "-Geotime<DateTimeOriginal#" image.jpg
and the geotag page gives multiple examples along these lines.  If you look at your output above, you can see multiple tags that already include the time zone, specifically the Subsec* ones.  So instead of trying to sync it your self, use the Geotime tag.
exiftool -geotag=../gpx_files/CDG\ 2022-05-13\ 10_49_03.gpx  '-Geotime<SubSecDateTimeOrigina#' ./IMG_0115.JPG

[babola]

Thanks so much for your response, I really appreciate it!

First, if I may be permitted a comment:
Cameras evolve.
You state yourself that the EXIF standard evolves, most recently in 2016  (SIX years ago).
Might I gently suggest, therefore, that ExifTool could also evolve, and support new functionality, based on new EXIF tags, if such tags happen to exist in an image file being processed?

Ok, back to the specific issue I raised: thanks for pointing me in the direction of -Geotime. Unfortunately, your suggested invocation...

exiftool -geotag=../gpx_files/CDG\ 2022-05-13\ 10_49_03.gpx  '-Geotime<SubSecDateTimeOrigina#' ./IMG_0115.JPG

... still doesn't work:

Code Select Expand

$ exiftool -v2 -geotag=../gpx_files/CDG\ 2022-05-13\ 10_49_03.gpx  '-Geotime<SubSecDateTimeOrigina#' ./IMG_0115.JPG
Loaded 318 points from XML-format GPS track log file '../gpx_files/CDG 2022-05-13 10_49_03.gpx'
  GPS track start: 2022:05:13 08:49:03.002 UTC
  GPS track end:   2022:05:13 09:39:21.499 UTC
Writing File:Geotag
======== ./IMG_0115.JPG
Setting new values from ./IMG_0115.JPG
Warning: No writable tags set from ./IMG_0115.JPG
Nothing changed in ./IMG_0115.JPG
    0 image files updated
    1 image files unchanged


Anything else I might try?

[babola]

Ok, sorry... there was a small typo in your suggested command (it was missing the final "l" in SubSecDateTimeOriginal#). Once I corrected that, the command worked!

Thanks again. You're free to "close" this topic, if that's something you do on this forum.

[StarGeek]

Ok, sorry... there was a small typo in your suggested command (it was missing the final "l" in SubSecDateTimeOriginal#). Once I corrected that, the command worked!

Ooops, sorry, thought I copy/pasted that but I guess I missed that.

Thanks again. You're free to "close" this topic, if that's something you do on this forum.

Nope, quite laid back and casual here.