Apply time-zone - add another option

[erichaas]

Preferences / Metadata 2 / XMP Import / Apply time-zone
currently has two settings: Yes, which applies the local time zone to File.DateTime, and No which ingores the time zone altogether. I would like to suggest a third option, to apply a user-specified time zone.

This could be useful to people who live in an area where daylight saving time or summer time is observed. Currently, if you take a photo during DST and edit it during standard time (or vice-versa), the File.DateTime of the edited photo will be updated, while the File.DateTime of other photos will not be, causing the edited photo to sort out of chronological order.

It could also be useful for people who are editing photos while traveling outside of their home time zone.

[PandDLong]

+1

[sdb]

+1

[Carlo Didier]

+1

[Mario]

causing the edited photo to sort out of chronological order.

Just sort by an XMP timestamp then? This will sort by the time-zone of the XMP tag.

It could also be useful for people who are editing photos while traveling outside of their home time zone.

Only if your camera does not record the correct time-zone in EXIF or you set IMatch to ignore the EXIF timezone. Else the time-zone of the POS is automatically applied when File.DateTime is generated.

[Carlo Didier]

Only if your camera does not record the correct time-zone in EXIF ...

Well, yes, as I often forget for the first days to change the time zone in all the cameras 

[Mario]

I have been thinking about adding a new user-defined time zone offset for IMatch 2023.
I'm not sure that I got the idea right, so some feedback would be welcome. Bear with me, time-zones are slightly difficult.

How it works currently:

IMatch has a global File.DateTime property which exists for all files, independent of the file format and metadata availability. This property and is used for sorting, display in File Windows etc.


File.DateTime has no time-zone offset and is assumed to be in the user's local time-zone.
This has historical, backwards-compatibility and technical reasons.

By default, IMatch uses existing metadata to determine File.DateTime and also looks for existing time-zone offsets in EXIF/XMP. Many modern cameras and smart phones record the time-zone in which an image was taken.
IMatch applies the metadata time-zone offset and the local time-zone offset to create File.DateTime.
See How IMatch uses Date and Time Information for detailed information.

The user has an option ("Apply time-zone") to disable this behavior. In that case, IMatch uses the EXIF/XMP timestamp 'as-is'. This is only for backwards compatibility reasons and should not be used in general.

This behavior may cause subtle issues. For example, if a user lives in Germany (UTC+02:00 hours with DST active) but ingests files into her/his database while being on a vacation in Australia (say, UTC+08:00), the File.DateTime will use the Australian time-zone, not the users "home" time-zone. This is sub-optimal.

Another issue is daylight saving time. The local time-zone offset reported by Windows always uses DST. So the File.DateTime may differ by +/- one hour, when the local-time zone is applied and DST is sometimes active and sometimes not. This is the correct behavior, but may not be the preference of some users.

My Idea for IMatch 2023

To deal with this issue and several other related issues, I plan to:

+ introduce a user-defined time-zone offset
+ use that offset (if set) whether or not the option "Apply time-zone" is enabled under Edit > Preferences > Metadata

This allows for several modes of operation:

NO CHANGE: Use existing time-zone offsets in metadata and apply the local time zone.
NO CHANGE: If the user-defined time-zone is not set, and "Apply time-zone" is off, use the metadata timestamp as-is

NEW: If the file system timestamp last resort must be used, always convert properly to the local time-zone.
NEW: If a user-defined time-zone offset is set, use that time-zone whether or not "Use time-zone" is enabled for metadata. This overrides the local time-zone offset.

Examples:

Timestamp found in metadata: 12:00:00 +07:00
Current time-zone (Germany with DST): +02:00

1. Default settings (Apply time-zone enabled, no user-defined time-zone offset configured)
File.DateTime: 07:00:00  (12-7+2)

2. Apply time-zone option set to off:
File.DateTime: 12:00:00

3. User-defined time zone offset set to: +05:00
File.DateTime: 10:00:00 (12-7+5)

The user-defined time-zone offset allows users to specify the time-zone to use when producing File.DateTime when importing files.

It also controls the time-zone offset used when IMatch has to fall back to using file system timestamps because there is no usable metadata in the file.
And this also controls the XMP date subject created, create date timestamp IMatch produces based on the file system timestamp when no other usable metadata timestamps are available.

For example, if the "created" timestamp of the file is 10:00:00 in UTC, and the user-defined time-zone offset is +05:00, IMatch sets XMP date subject created and create date to 10:00:00+05:00. If no user-defined time-zone offset is set and the local time zone is +02:00, the metadata dates would be 10:00:00+02:00.

Let me know what you think.

[jch2103]

This probably won't affect me, as I always set local TZ in my cameras (including on trips to Australia and Europe). (Slight correction: one of my older cameras doesn't set TZ, but I do correct this.) But it could be useful to some users.

[Mario]

I have been thinking about adding a new user-defined time zone offset for IMatch 2023.
I'm not sure that I got the idea right, so some feedback would be welcome. Bear with me, time-zones are slightly difficult.

How it works currently:

IMatch has a global File.DateTime property which exists for all files, independent of the file format and metadata availability. This property and is used for sorting, display in File Windows etc.


File.DateTime has no time-zone offset and is assumed to be in the user's local time-zone.
This has historical, backwards-compatibility and technical reasons.

By default, IMatch uses existing metadata to determine File.DateTime and also looks for existing time-zone offsets in EXIF/XMP. Many modern cameras and smart phones record the time-zone in which an image was taken.
IMatch applies the metadata time-zone offset and the local time-zone offset to create File.DateTime.
See How IMatch uses Date and Time Information for detailed information.

The user has an option ("Apply time-zone") to disable this behavior. In that case, IMatch uses the EXIF/XMP timestamp 'as-is'. This is only for backwards compatibility reasons and should not be used in general.

This behavior may cause subtle issues. For example, if a user lives in Germany (UTC+02:00 hours with DST active) but ingests files into her/his database while being on a vacation in Australia (say, UTC+08:00), the File.DateTime will use the Australian time-zone, not the users "home" time-zone. This is sub-optimal.

Another issue is daylight saving time. The local time-zone offset reported by Windows always uses DST. So the File.DateTime may differ by +/- one hour, when the local-time zone is applied and DST is sometimes active and sometimes not. This is the correct behavior, but may not be the preference of some users.

My Idea for IMatch 2023

To deal with this issue and several other related issues, I plan to:

+ introduce a user-defined time-zone offset
+ use that offset (if set) whether or not the option "Apply time-zone" is enabled under Edit > Preferences > Metadata

This allows for several modes of operation:

NO CHANGE: Use existing time-zone offsets in metadata and apply the local time zone.
NO CHANGE: If the user-defined time-zone is not set, and "Apply time-zone" is off, use the metadata timestamp as-is

NEW: If the file system timestamp last resort must be used, always convert properly to the local time-zone.
NEW: If a user-defined time-zone offset is set, use that time-zone whether or not "Use time-zone" is enabled for metadata. This overrides the local time-zone offset.

Examples:

Timestamp found in metadata: 12:00:00 +07:00
Current time-zone (Germany with DST): +02:00

1. Default settings (Apply time-zone enabled, no user-defined time-zone offset configured)
File.DateTime: 07:00:00  (12-7+2)

2. Apply time-zone option set to off:
File.DateTime: 12:00:00

3. User-defined time zone offset set to: +05:00
File.DateTime: 10:00:00 (12-7+5)

The user-defined time-zone offset allows users to specify the time-zone to use when producing File.DateTime when importing files.

It also controls the time-zone offset used when IMatch has to fall back to using file system timestamps because there is no usable metadata in the file.
And this also controls the XMP date subject created, create date timestamp IMatch produces based on the file system timestamp when no other usable metadata timestamps are available.

For example, if the "created" timestamp of the file is 10:00:00 in UTC, and the user-defined time-zone offset is +05:00, IMatch sets XMP date subject created and create date to 10:00:00+05:00. If no user-defined time-zone offset is set and the local time zone is +02:00, the metadata dates would be 10:00:00+02:00.

Let me know what you think.

BUMP.

[Jingo]

I too try to remember to set my cameras to local time when shooting and want that same time to appear in IMatch when reviewing photos.  I think a method to allow users to manage this easier is always welcome though!

[thrinn]

This probably won't affect me, as I always set local TZ in my cameras (including on trips to Australia and Europe). (Slight correction: one of my older cameras doesn't set TZ, but I do correct this.) But it could be useful to some users.

For me it is the same: I always set my camera to the local time of the location I am visiting. Never had problems with the existing options. Wrong date and time was mostly caused by me, forgetting to set the cameras time correctly. But for this kind of problems we have the Time Wizard.
Still, I also think that this could be useful for others or in the (for me) very rare cases where IMatch is forced to use some filesystem timestamp.

[Mario]

This enhancement will be included in IMatch 2023.

[vbt]

I am not sure I understand what is being proposed since it seems to be aiming to achieve something I would have thought most people would consider undesirable.
 
Even if I had full timezone details for all my photos I would want the time element of the File.DateTime value to remain in the local time where the photo was taken.
 
So if I took a photo in New York City at 2pm I would expect the File.DateTime to remain shown as 14:00:00-05:00. I would never want it to be shown as 19:00:00+00:00, even though I live in an area on UTC. And I would consider a date recorded in this second format in metadata to be incorrect even though it refers to the same point in universal time. The metadata would be saying the photo was taken in a timezone on UTC when that was not the case.
 
If I have misunderstood the proposal, and there is no risk of Imatch changing the time format of photos then apologies in advance.

[Mario]

This is just another option to make the File.DateTime more flexible for certain use cases.

By default, this process will work in IMatch 2023 as it works now.
Unless you use the new user-defined time-zone offset to override the default time-zone handling when IMatch is setting File.DateTime from metadata when indexing files.

IMatch applies the local time-zone (when you enable it under Edit > Preferences > Metadata 2) when converting the metadata timestamp into File.DateTime.

If you are not in your regular time-zone (e.g., on location or while traveling) when IMatch ingests new files, this may result in unexpected results. All easy to correct with the TimeWiz later, but the new option allows you to use your home base time zone wherever you are.

What makes all this a bit complicated are the multiple time-zones which come into play. The metadata timestamp may have a time-zone or not - depending on the device used. The current time-zone in Windows may or may not be your home time-zone. DST may be active or not...

[akirot]

I'm confused.
Reading Mario's description it's not clear to me how timestamps are handled or will be treated in future versions.
Apparently timezones and OffsetTimes are not clearly distinguished from each other - they serve different purposes!

A fully qualified timestamp consists of:
localtime + timezone + DST

OffsetTime equals to:
timezone + DST

The timezone(!) of a given location "never" changes; e.g. Germany always has UTC+1.
OffsetTime(!) varies as it includes DST, in Germany resulting in an OffsetTime of 1 hour in winter and 2 hours during summer.

Time at a given location in UTC equals to:
localtime - OffsetTime

Isn't a new IMatch version 2023 the(!) chance to rethink old habits, simplify things and define file.datetime as time in UTC?
(Where necessary a one time migration could be performed when upgrading from an existing version to IMatch2023.)
Probably the Help/Description should be cleaned up at least to precisely differentiate between timezones and OffsetTimes.

[Mario]

Nothing changes to the current behavior unless you see the need to force IMatch to use a timezone other that the local time-zone when calculating File.DateTime.

IMatch always uses metadata timestamp + time-zone offset (if available in metadata) and then transforms that to local time using the current local time zone.

The new option just adds more flexibility for the very small percentage of users who move between time-zones while adding and updating files to their database. Different local time-zones will produce different File.DateTime values. Easily to correct with TimeWiz of course once the user is back at her/his home base.

When I write a new IMatch version some day, I will use UTC as the base for the global File.DateTime.
This will not end confusion, though. If DST comes into play, the time shown based on File.DateTime will change. If you look at your database in a different time-zone (on-location, traveling, ...) the value displayed for File.DateTime will be also be different. Unless File.DateTime is always displayed as native UTC or with a varying time-zone offset relative to the current time-zone and DST state.

Needless to say that users can always choose to sort by a different timestamp or to display/use metadata timestamps with time-zone offset instead of File.DateTime.