Python APP - Add Timezone Offset

[sdb]

I expect few people (none?) will have any interest in the purpose of this app, but I thought I would post it anyway as I wanted the functionality and I found it an interesting exercise in developing a python app for iMatch.  Python was needed to access libraries not available in JavaScript.

The app operates on all files currently selected in iMatch, and modifies the Date Subject Created date by adding to it an appropriate timezone offset.  The time zone is determined by GPS coordinates associated with the file, or if no coordinates are available, a default time zone is assumed.

The command line options for the app are:

Code Select Expand

options:
  -h, --help    show this help message and exit
  -deftz DEFTZ  Specify default timezone, (e.g. -deftz Europe/Oslo) for use when there are no GPS coords. If omitted, 'Europe/London' is default.
  -user USER    Specify user name alias if this has been set in iMatch Application settings. Otherwise not needed
  -createdate   Normally Date Subject Created is populated. By specifying this option, the same contents are also written to Create Date
  -v            Verbose output
  -np           Do not pause output for confirmations


Installation

You need 64 bit Python 3.8, 3.9 or 3.10. 

I recommend using a virtual environment (venv) for the python code.  After setting up the venv, from the command line: 

Code Select Expand

pip install -r requirements.txt

Then a Favourite can be created:
The Command to Execute should be: 

Code Select Expand

"<path_to_python.exe_in_the_venv>"

The Arguments should be

Code Select Expand

"<path_to_add_timezone.py>" <options>

You can create multiple Favourites with different names/options , e.g. for different default time zones.

Notes

The date calculated by the app ignores any pre-existing timezone offset, and is based on (in order of priority): 
Exif DateTimeOriginal 
XMP DateTimeOriginal 
XMP:Photoshop Date Created (i.e. Date Subject Created) 

This app just changes the Date Subject Created field (and optionally Create Date) but as usual writeback propagates the change to other fields.

This app only makes sense in the context of storing, in Date Subject Created, the local date (relative to where the image was taken) with the timezone offset for that location.   This only works if "Metadata 2/XMP Import/Apply time-zone" is set to No when the images are imported.  Otherwise imported files will have their File.DateTime manipulated in dependence on the location of the computer running iMatch and whether Daylight Savings is in effect at the time of import.

PS The python code is add_timezone.py but I had to zip this in order to upload.

[Mario]

Thanks for sharing 

I'm not sure about all the details you have coded in your custom app, but could this not be done with the Time Wiz app in IMatch?
Variables give you access to the GPS timestamps and offsets, if existing, and conditionals could pick the "best" timestamp for your specific device and metadata content.

[sdb]

Hi Mario.  You may be correct that TimeWiz could be used - I did try this first - but if so it is currently beyond my ability to work out a convenient workflow.

The reasons include:
- TimeWiz seems to want a literal for specifying a changed time zone, rather than a variable
- many of my images were restrospectively geotagged and have no GPS timestamps/offsets
- Although I often know where pictures were taken (even if not geotagged) I don't know the timezone offset so I would prefer this be automatically found (from GPS or by specifying the name of the timezone)
- I will often not be able to determine if Daylight Savings Time should be applied
- I don't know what you mean by "conditionals" - are these something you can automate?
- It seems that you would have to keep changing the TimeWiz settings to match different situations, which could be time-consuming and error-prone.

Actually I was going to post separately about this last point.  I have used the excellent TimeWiz quite a lot, and I think it would be further improved if you could name and save settings so they could be quickly retrieved.

PS My comments about the Metadata 2 setting may not be accurate - I don't seem to be able to edit my post.  I meant to say that the setting was needed if you want File.DateTime to match the local time when the image was taken - by far the best arrangement in my view.  But not strictly necessary for my app.

[Mario]

TimeWiz seems to want a literal for specifying a changed time zone, rather than a variable

When you use the set from variable option, you can also set the time-zone offset from any metadata tag that contains the correct information.

I don't know the timezone offset so I would prefer this be automatically found (from GPS or by specifying the name of the timezone)

The standard defines that EXIF metadata may/should include a time zone offset. This of course depends on the device used to record the image.
When there is an EXIF time-zone, IMatch detects and applies it. IMatch does not look for time-zone offsets in GPS records, QuickTime video track segments, proprietary maker notes or elsewhere.

When a small number of users have to deal with the problem that their device has not recorded time-zone offsets in EXIF but in GPS, or the GPS data has been added later somehow, setting the time-zone via the TimeWiz is usually quick and easy to do. Either by adding a fixed time-zone offset or by using a variable to fetch the offset (e.g. from GPS data) and apply it to the date created and date subject created tags.

I understand that there might be cases where not even the TimeWiz can help, but these should be very rare. And then your Python script comes in.

[sdb]

I use this app all the time.  I'm not sure anyone else does, but just in case here is an updated version.

This allow the port number to be an input parameter to deal with the possibility of iMatch using a non-default port.  

It also fixes a potential problem with CreateDate.  Previously, CreateDate was only changed to match Date Subject Created if the -createdate option was selected.  But if this isn't selected, changes to Date Subject Created could in certain circumstances trigger a mapping operation resulting in a possibly-unwanted change to CreateDate (just like if you changed Date Subject Created in the normal iMatch UI).

To deal with this, if you don't choose to copy Date Subject Created to CreateDate, then CreateDate will be re-populated with its current date to prevent unwanted changes. (This was happening in the earlier version but not robustly.)

The command line options for the app are:

Code Select Expand

options:
  -h, --help    show this help message and exit
  -deftz DEFTZ  Specify default timezone, (e.g. -deftz Europe/Oslo) for use when there are no GPS coords. If omitted, 'Europe/London' is default.
  -user USER    Specify user name alias if this has been set in iMatch Application settings. Otherwise not needed
  -createdate  Normally Date Subject Created is populated. By specifying this option, the same contents are also written to Create Date
  -v            Verbose output
  -np          Do not pause output for confirmations
  -p P          Port number - defaults to 50519