Update Timestamps based on "Geolocation Time Zone"

[DD]

I hate Date/Time/Timezone confusion, so I keep my camera time set in UTC, which (conveniently) matches my GPS logs. However, it would be nice to have the local time for an image available.

I noticed the geolocation feature mentions the Time Zone. So I have been working on this processing sequence (which is probably not optimal):

• Update all date/time for any clock drift
• Set copyright to include year
• Geotag images
• Geolocate images
• Store local time calculated from (corrected) DateTimeOriginal in UTC and Geolocation Time Zone

All is now working (after much searching on this forum) except the last step. Is this possible? (I don't see the Time zone saved to the file.)

Finally, if this can be done, is there a recommended (existing) metadata field to store the local time?

(Sorry if this has been answered before, but my searching failed to find anything.)

[StarGeek]

I noticed the geolocation feature mentions the Time Zone.

I believe that it includes the Time Zone ID/Name, e.g. America/New_York, not time zone offset.

Time zone names don't really change that much, so it's simple to include. Actual time zone offsets, while stable in some regions, aren't necessarily in others. Obligatory link to Tom Scott's discussion on time zones.

is there a recommended (existing) metadata field to store the local time?

Yes, the EXIF time stamps, CreateDate, DateTimeOriginal, and ModifyDate. Their purpose is to hold local time.  For UTC, you would use the GPS time stamps, GPS:GPSDateStamp, EXIF:GPSTimeStamp, and the less common XMP:GPSDateTime.

Time zone numbers would be held in OffsetTimeDigitized, OffsetTimeOriginal, and OffsetTime.

It's up to you how you want to use the tags, but if you might think about copying the EXIF time stamps to the GPS ones and then adjust the EXIF ones.

[Phil Harvey]

@StarGeek:  I've just figured out how to get the API TimeZone option working in Windows, and ExifTool 12.84 will include this patch.  I've tested it, and it works with time zone offsets in Windows, but not time zone ID's.  Note the sign of the offset is opposite to what I would expect (eg. New York is "+04:00").

@DD: As StarGeek said, the GeolocationTimeZone tag provides a time zone ID, not an offset.  I thought about a feature to set the API TimeZone option automatically from this tag, but unfortunately I haven't been able to get the API TimeZone option to work on Windows with a time zone ID.  (Although I did just make some progress and got this working with an offset.)

- Phil

Edit: Time zone names like "EST5EDT" also seem to work in Windows.

[StarGeek]

Edit: Time zone names like "EST5EDT" also seem to work in Windows.

Yeah, I previously worked through that mess.  Basically, the letters don't matter. ABC5XYZ is treated exactly the same as EST5EDT.  And I strong suspect that there would be problems with time zones that aren't integers (see Australian time zones)/Nepal time zone), though I don't recall if I checked that out or not.

[Phil Harvey]

I tested this too, but I found that the letters do matter.  EST5 is different than EST5EDT.  EST5EDT is either +04:00 or +05:00 depending on the date.

- Phil

[StarGeek]

EST5 is different than EST5EDT.  EST5EDT is either +04:00 or +05:00 depending on the date.

Yes.  It's the existence of the second set of letters that causes this.  It doesn't matter what those letters are.

Try using a time zone that is four or more letters.  For example, Easter Island Standard/Daylight Time, EAST/EASST. Four letters will put the number out of place, and you end up with Western European Time (WET +00:00/WEST +01:00).

An additional test that can't be replicated on Windows.  On Mac/Linux, set the time zone to America/Los_Angeles.  Now set the date to something after March 11, 2007 and before April 11, 2007. For example, 2007:03:20 12:00:00. The time zone should be -07:00, as it was PDT in LA on that date.

Now set the time zone to America/Tijuana.  The time zone should be -08:00.  That is because in 2007, the US changed the start date for Daylight Savings time to March 11. Mexico did not and was still using PST, and didn't start Daylight time until April 1.

Windows isn't looking at the letters, otherwise nonsensical "time zones" like ABC shouldn't work.  It just parses the number in the 4th position and adds Daylight savings adjustment if there is any letters after the number.

[Phil Harvey]

Ah, I see.  Very interesting.  Thanks for explaining this.

- Phil

[StarGeek]

Yeah, this was an insane rabbit hole I went down in my other post, spending several hours trying to make sense of it.

I also just realized that I didn't try any Southern Hemisphere time zones, such as Australia, which are going to have daylight savings time reversed. But I don't think I want to dig back into it again. It's just so poorly documented without how it actually works and there isn't much useful info otherwise.