About Time...

[Mario]

I would appreciate your feedback on this IMatch 2023 topic.

Background

For historical and backwards-compatibility reasons, IMatch assumes that the global File.DateTime attribute (see IMatch File.DateTime) is in your local time-zone. IMatch does this since version 3, and at that time, the FAT file system stored timestamps in local time. Anyway...

For IMatch 2023 I want to finally move File.DateTime to be in UTC (GMT). IMatch stores other timestamps like the last modification date, database timestamps in UTC already, so this is a sensible step.

Unfortunately, time is complex
Here is where I would appreciate your feedback and insights.

1. Mapping existing File.DateTime to UTC during database migration.

Assuming that existing timestamps are in your local time-zone, IMatch can produce the UTC timestamp by adjusting the existing File.DateTime in your database accordingly, to make them UTC.

Slight problem: Daylight saving time (DST). The resulting timestamp may be off by one hour, depending on whether or not DST was active when IMatch update the File.DateTime the last time. But in fact this was always the case, so things are not worse than before.

2. Mapping Metadata Timestamps in the Future (IMatch 2023 and onward)

2.1 UTC and Local Time

File.DateTime will always be stored in UTC internally. When the timestamp is needed in your local time zone (e.g. for the File Window date & time, sorting, the {File.DateTime} variable, IMatch converts from UTC into your local time zone automatically. This is better than before, since DST and a changed clock is automatically respected.

I will provide attributes and variables, e.g. {File.DateTime.UTC} and {File.DateTime.LocalTime} to explicitly request the File.DateTime in local time or UTC. This can be useful in certain situations.

2.2 Now for the Tricky Part...

How does IMatch produce File.DateTime in UTC?`
If the metadata of a file contains valid time-zone offset information (e.g. the EXIFTimeZoneOffset tag), IMatch applies that to the date subject created timestamp. This produces a reliable UTC timestamp.
There are some other file formats which store time-zone data in proprietary metadata tags. These will be used in the same manner.

When a file has no time-zone offset, IMatch cannot know if the timestamp is in UTC, in your local time-zone or in some other time-zone. Or if the camera clock was off etc.

To deal with this, I plan to add several mapping modes, which control how IMatch maps metadata timestamps to UTC:

1. Default: Use only time-zones from metadata.
If there no time-zone information is available, assume the timestamp is in UTC

2. If a file has no metadata time-zone, use the local time-zone

3. If a file has no metadata time-zone, use the local time-zone and ignore DST

4. Apply the local time-zone only (ignore metadata time-zone)

5. Apply the local time-zone only (ignore metadata time-zone) and ignore DST

6. Apply the user-defined time-zone in addition to the metadata time-zone
(You can input a HH:MM time-zone offset to use in Edit > Preferences > Metadata 2.)

7. Apply the user-defined time-zone only

As usual, when a file comes in or is modified externally or when users change the date subject created (MD Panel, TimeWiz), the File.DateTime is automatically updated, applying the rules above.
This also allows for manually correcting of wrong File.DateTime by adjusting the date subject created or adding the correct time-zone.

Example:

A file has the timestamp timestamp 11:00:00 (date subject created or equivalent) but no time-zone.
We are in Germany, which is UTC+01:00. User-defined time-zone is +04:00.

1: 11:00:00 or something else, if there is time-zone information available in the image.
2: 10:00:00 or 09:00:00 if DST is on.
3: 10:00:00
4: 10:00:00 or 09:00:00 if DST is on (metadata time-zone always ignored).
5: 10:00:00 (metadata time-zone always ignored).
6: 07:00:00
7. 07:00:00 (metadata time-zone always ignored).

Does this cover all bases and use-cases?
My own requirements are very minimal. I check the clocks of my cameras always before shooting, I set the time-zone correctly and my images hence always have all the info needed to set File.DateTime.

[mastodon]

This would be fabolous! It is a really tuff problem, I know, and need very hard work.

I have a lot of problem with time. My camera is not always have the good DST setting (or does not have any), so TimeZoneOffset is wrong or missing. Sometime I forgot to set the proper time and/or TimeZoneOffset after crossing time zone or after summer time... So I have a great variety of problems to solve.
Could IMatch have an algorithm, that check and set/repair the TimeZoneOffset, if the file have GPS data? (I have a lot of files, that have manual GPS data)

[JohnZeman]

It seems to me this could be a lot of work for people like me who always save the timestamps to the local time of the time zone I'm currently in when I'm in other time zones.

For example if my photos were taken in the west coast local time zone, which is -2 hours different than the local time zone in Iowa where I live, how would IMatch determine what the UTC time zone of the west coast local time is?

[Mario]

Could IMatch have an algorithm, that check and set/repair the TimeZoneOffset, if the file have GPS data? (I have a lot of files, that have manual GPS data)

When you set a time-zone offset in the Metadata Panel or via the Time Wiz app (which is actually designed to deal with the kind of problems you are facing), the TimeZoneOffsets in the metadata will be written when IMatch writes back (assuming you add time-zone offsets to date subject created and create date. This preserves the timestamps for applications which don't handle XMP.

[Mario]

For example if my photos were taken in the west coast local time zone, which is -2 hours different than the local time zone in Iowa where I live, how would IMatch determine what the UTC time zone of the west coast local time is?

Your camera should record the time-zone offset in the metadata. If you set the clock right for the place of shooting, you'll be fine.

If your clock is off or set to the wrong time-zone or DST, the timestamps and time-zone offsets in your images will be wrong.
IMatch has no way to tell.

You either need to fix the wrong timestamps with the Time Wiz (which also corrects File.DateTime) or you use option 7 from above, which forces a specific time-zone (right or wrong) for all files. Which makes sense only in rare cases.

This feature is not about "correcting" wrong timestamps. It's about how IMatch should derive a File.DateTime in UTC from metadata. If your camera does not record time-zone offsets or the clock or time-zone offset is wrong, there will be problems which need manually fixing in TimeWiz.

[JohnZeman]

That's what I meant.  My older cameras did not record the timezone so I manually set the local time of the timezone without establishing any timezone.

[Mario]

When your older cameras did not add a time-zone and IMatch ingests the files, it will by default do 1 (use the date 'as-is') unless you enable one of options 2 to 7. If there is no time-zone in the file, IMatch assumes the timestamp is in UTC.

If you enable option 2, IMatch uses the local time zone (at the day the file is ingested) to calculate the UTC timestamp. This is how IMatch works now.

But with a notable difference: If you ingest a file with the timestamp 11:00:00 in a time-zone UTC +04:00, IMatch sets File.DateTime to 07:00:00 and remembers the +04:00 time-zone. When you later display the file in a time-zone +02:00, IMatch displays File.DateTime in your local time-zone as 09:00:00.
Before, it would have displayed 07:00:00, without any indication of the time-zone offset responsible for this.

This gives us even more to think about.

I have designed this new processing in a way that IMatch not only calculates the File.DateTime in UTC, but also records the time-zone offset used for this calculation.

In my example above, IMatch calculates 07:00:00 UTC and remembers +04:00.
This allows us to display the File.DateTime in several ways:

11:00:00 => Using original time-zone
11:00:00+04:00 => Using original time-zone

07:00:00Z => In UTC

09:00:00 => If you display File.DateTime in local time in a +02:00 time-zone
09:00:00+02:00 => If you display File.DateTime in local time in a +02:00 time-zone

As I said, time is complicated and I want this to get right and comfortable for the widest possible audience.

[mastodon]

For me this would be perfect. See original data, UTC converted and UTC with timeoffset.

[akirot]

Finally you do it - thank you!
My files (should) all have offset times - a conversion should be easy.
Probably Part 2 ("Mapping...") can be made available as an app (similar to the Metadata mechanic) with selectable options.
Thus the user can convert/correct selected files later (or again if the first selected conversion option has been "wrong".)
This makes it repeatable for the user and hopefully reduces support requests.

[Jingo]

I have to think about this a bit and review my files... not sure how my timestamps are used buy the file.date.time is how I sort my images by default so having a correct order is quite important!

[Tveloso]

This will be great!

I have to think about this a bit and review my files... not sure how my timestamps are used buy the file.date.time is how I sort my images by default so having a correct order is quite important!

But yes, this can get quite complicated.  And I expect that the technique used in the migration of the current File.DateTime values will be important.

Mario, wouldn't using Option-2 (how IMatch works now) by default, for the Migration be better?...(so as not to change the "displayed value" for files that lack a UTC Offset)...

It seems to me this could be a lot of work for people like me who always save the timestamps to the local time of the time zone I'm currently in when I'm in other time zones.

For example if my photos were taken in the west coast local time zone, which is -2 hours different than the local time zone in Iowa where I live, how would IMatch determine what the UTC time zone of the west coast local time is?

It seems that this is the biggest concern - files which lack a UTC Offset.

That's what I meant.  My older cameras did not record the timezone so I manually set the local time of the timezone without establishing any timezone.

John, it's not clear to me if you mean that you set the local time where the photo was taken, or if you "restate" that time in your home timeZone (but I understand that in bath cases, you did not include a UTC Offset). 

If it's the local time in your home timeZone (i.e. you took the photo at 11:00 AM in California, which is 1:00 PM in Iowa, so you set the time to 1:00 PM), then you'll be ok with Option-2 as Mario says.  But if that file says 11:00 AM, then IMatch has no way to know that was 11:00 AM Pacific, and not Central.

Based on this, I thought that it might be prudent to try to populate a UTC Offset into Files that lack one, based upon available location data.  I thought that perhaps a Data-Driven category could isolate all files that lack a UTC Offset (perhaps based on then length of the value in XMP::photoshop\DateCreated\DateCreated\0 - less than 20 Bytes means that timeStamp contains no offset?), and then we could filter that using the Category Filter for Location.  So in John's case (assuming that he did not "restate" the time in his home TimeZone), he could select all files taken in California, and store -8:00 as the UTC Offset, and set -6:00 for his Iowa files.  But then DST needs to be considered - photos taken in the summer would need -7:00 and -5:00 respectively in California and Iowa...

As I was exploring doing something like this, I found that some of my files that I was certain should contained a UTC Offset, actually didn't (at least not in DateCreated).

For example, for a File with these timestamps:

   

...or to re-display DateCreated in a format we'll all understand:

    

...the ECP shows that there is in fact a UTC Offset available (ExifTool derived one for Date/Time Original in the Composite Group):

Code Select Expand

[System]            - File Modification Date/Time    : 2022:09:02 10:51:53-04:00
[System]            - File Access Date/Time          : 2023:01:06 07:53:13-05:00
[System]            - File Creation Date/Time        : 2022:12:13 19:42:19-05:00
[IFD0]            306 Modify Date                    : 2022:09:02 10:51:53
[ExifIFD]      36867 Date/Time Original              : 2022:09:02 10:51:53
[ExifIFD]      36868 Create Date                    : 2022:09:02 10:51:53
[XMP-photoshop]    - Date Created                    : 2022:09:02 10:51:53
[XMP-xmp]          - Modify Date                    : 2022:09:02 10:51:53
[XMP-xmp]          - Create Date                    : 2022:09:02 10:51:53
[IPTC]            62 Digital Creation Date          : 2022:09:02
[IPTC]            55 Date Created                    : 2022:09:02
[Composite]        - Create Date                    : 2022:09:02 10:51:53.143-04:00
[Composite]        - Date/Time Original              : 2022:09:02 10:51:53.143-04:00
[Composite]        - Modify Date                    : 2022:09:02 10:51:53-04:00
[Composite]        - Date/Time Created              : 2022:09:02 10:51:53
[Composite]        - Digital Creation Date/Time      : 2022:09:02 10:51:53

So why wasn't the Offset included in XMP::photoshop\DateCreated\DateCreated\0?  I don't think that I've done any writebacks for this file, so it already contained an XMP record?...(lacking the Offset in DateCreated)

This is definitely tricky.

How will IMatch migrate this file?  Will it use the -4:00 Offset available in the file (even though it's missing in DateCreated)?...or will it use my current Offset (which is -5:00)?...

[Mario]

Mario, wouldn't using Option-2 (how IMatch works now) by default, for the Migration be better?...(so as not to change the "displayed value" for files that lack a UTC Offset)...

When migrating existing File.DateTime, IMatch use one of these schemes:

A) Use the existing File.DateTime (which is supposed to be in the correct local format) and calculate the UTC from it using the current time zone offset. This is equivalent to 2.
There would be no change if File.DateTime is displayed on local format (like it is now). IMatch would just calculate the local time from the UTC.

B) Looking at existing metadata (date subject created), which should always be filled and valid (it is filled by IMatch unless the user disables that explicitly). Or it has been filled by the user.
If this timestamp has no time-zone offset, IMatch would treat it as local time and calculate the UTC from it.

The migration runs when the database is first opened, before the database is loaded or any user interface is available. It must be automated. The user can correct the timestamps later as needed.

Currently my idea was to assign files without a time-zone offset found during migration to a category. The user can check the timestamps and if he/she is one of the many who always uses their local time-zone in-camera, nothing has to be done. Else the files are easily to select and modify in the TimeWiz, e.g. by specifying a proper time-zone offset. IMatch would then calculate File.DateTime again from the now corrected / time-zoned timestamp.

[Tveloso]

Currently my idea was to assign files without a time-zone offset found during migration to a category. The user can check the timestamps and if he/she is one of the many who always uses their local time-zone in-camera, nothing has to be done. Else the files are easily to select and modify in the TimeWiz, e.g. by specifying a proper time-zone offset. IMatch would then calculate File.DateTime again from the now corrected / time-zoned timestamp.

That's a great idea!

[thrinn]

Currently my idea was to assign files without a time-zone offset found during migration to a category.

A category would be great. I certainly would want to check files where File.DateTime was "changed" by the migration process. 

As a special case I use a second DB for documents (PDF mostly) like invoices, bank or insurance statements and such. These files do not necessarily have a Date Subject Created information (I just checked). They may have something like PDF Create Date - but without time zone. For this kind of files I do not care at all for the time information, but I do care about the date. If, for whatever reasons, the date is changed by the migration process, I want to be able to find the files that were changed.

[stefanjan2]

For me personally, after struggling and failing to use and offsets to align photos from two cameras and a phone, questioned why I need offsets. Simplest thing for me I feel is just to set cameras to local time if I remember, if not set to local time in imatch when I get back from a trip.

For my personal use, it is more important that photos taken on different devices are in the correct time sequence and show the time in that location. The actual time in the UK is not that relevant to me.

Appreciate for many users time is important.

[Tveloso]

For me personally, after struggling and failing to use and offsets to align photos from two cameras and a phone, questioned why I need offsets. Simplest thing for me I feel is just to set cameras to local time if I remember, if not set to local time in imatch when I get back from a trip.

If I understand correctly, like other users have described here, you would prefer for IMatch to display only "the TimeStamp portion" of the value in DateCreated, without regard to the UTC offset the file may contain, correct?  So for you, two files with these TimeStamps:

    2023:01:10 11:00:00+00:00
    2023:01:10 11:00:00+01:00

...should both say 11:00 AM in File.DateTime (even though they were actually taken an hour apart), correct?

Currently, IMatch allows us to achieve that, by turning off the Apply TimeZone flag in Edit->Preferences->Metadata2.

Mario, will IMatch 2023 still allow that behavior?

[stefanjan2]

If I understand correctly, like other users have described here, you would prefer for IMatch to display only "the TimeStamp portion" of the value in DateCreated, without regard to the UTC offset the file may contain, correct?

To be honest I'm struggling to understand how this works. Thought I did but got in a mess trying to correct.
I'd be reluctant to make a global change to existing photos because I've got them all displaying the correct time.
So from my recent trip to Canada, as created date. I have a 8 hour offset on my main camera and no offset on my compact camera and mobile phone. All are now showing the correct time in the file window. I tried to correct all of them with an -8 hour offset in the created date but for whatever reason could not seem to get a consistent result in the File window.

My current thinking going forward is that I set the cameras to local time without an offset or adjustment for daylight saving. If I forget then I will correct after in imatch.

For me, knowing what the UK local time was is unnecessary but fully understand that for many this will be essential.

[Mario]

Mario, will IMatch 2023 still allow that behavior?

No. IMatch 2023 will always derive the File.DateTime in UTC and store that in the database. This implicitly requires to use the existing time-zone offset in the file (if any) or, depending on the mode selected by the user, apply the local time-zone or the user-defined timezone. Mode makes the old ApplyTimeZone option unnecessary.

When File.DateTime is later displayed somewhere (e.g. File Window Date & Time Attribute), IMatch converts the UTC timestamp into local time. The local time at that moment, which adjusts for the active time-zone and active/inactive DST. This is one of the main improvements coming from the change to UTC.

IMatch 2023 offers additional FileWindow attributes to display File.DateTime in UTC and, if I see a need, the File.DateTime in local time with the current time-zone offset or others.

New variables have been added, e.g. {File.DateTime.UTC} to access the UTC timestamp and {File.DateTime.UTCOffset} which returns the formatted UTC offset used to calculate File.DateTime during ingest (from metadata time-zone, local time-zone or user-defined time-zone) and {File.DateTime.UTCOffsetInMinutes}, which returns the UTC offset used to calculate File.DateTime in minutes as a number. Could be useful when performing date & time math with variables.

I'm also pondering to create a variable which returns File.DateTime in an arbitrary time-zone, e.g. to display the file date & time for a specific region and/or the current region. Not sure if there is sufficient demand for this.

Looking at the the comparatively small number of users providing feedback to this thread, most users just don't care that much about time. Or always shoot in their local time-zone and hence never run into any issues.

For me, switching this last timestamp from "forced local time at ingest" to UTC was long due. File.DateTime was basically introduced in IMatch 3, when dinosaurs still roamed the world, metadata barely existed and the Windows file system used timestamps in local time - with all the funny side-effects when DST became activated or deactivated.

The crux with this major change is a) compatibility with existing IMatch databases and b) incorporate all the options needed by users who face specific challenges. The default settings take care that the majority of the user base won't even notice this change.

[sinus]

Mario, will IMatch 2023 still allow that behavior?

...
Looking at the the comparatively small number of users providing feedback to this thread, most users just don't care that much about time. Or always shoot in their local time-zone and hence never run into any issues.
...

This means, users (including me), who does exactly this, shoot in the own local time-zone, including take care of the summer/winter-time, they will not be affected from this new major change?

And the file name, which many users have chosen depending on the file time, is not affected, even if the file name is no longer exactly the same as the "IMatch date-time" due to the change?

[Mario]

No.
The new method of calculating File.DateTime will not affect file names.
If you use the {File.DateTime} somehow to produce your file names, you will get local time as before.

BUT, if you change the computer clock, time-zone or summer/wintertime, the displayed File.DateTime will change accordingly.
Before, File.DateTime was calculated once, when a file was ingested. And the timestamp was frozen. If DST came into play or the computer clock was changed, File.DateTime did not change. It was always presented as recorded.

Now, the timestamp is stored as UTC, which means it can be displayed in local time correctly, even if the clock is changed or DST switches to on/off or the computer is moved into a different time-zone. You will always see the timestamp in the correct local date and time.

[sinus]

Thanks a lot, Mario.
I think, I understand now a bit more 

If IMatch 2023 will be out, I will look into this deeper, because to be honest, I have understood most of this date-time-stuff, but not fully and enough deep. 

But I have not doubt, that you will drive IMatch in the best direction, what makes sense. 

[Mario]

If IMatch 2023 will be out, I will look into this deeper, because to be honest, I have understood most of this date-time-stuff, but not fully and enough deep. 

This is why I said in my first post above:

Unfortunately, time is complex  

Dealing with time-zones, local and active when an image was taken etc. is complicated.
Furthermore, different groups of users have different demands. Some don't care at all, others consider the recording time and display time to be very important.

[rolandgifford]

Looking at the the comparatively small number of users providing feedback to this thread, most users just don't care that much about time. Or always shoot in their local time-zone and hence never run into any issues.

Or they do care and happen not to have read this thread sooner, which is my case.

I'm confused about the benefit of changing any of this.

I adjust my camera clock so that it shows the local time of where I am visiting. Our cameras have the option of doing this by selecting a different time zone but I find it simpler and therefore safer to simply reset the clock. Daylight saving can confuse the time zone offset as has already been mentioned.

After taking photos and importing to IMatch I want to see the time for the photo location. I have no interest whatsoever what time that represents at home. I'm puzzled why anyone would want anything else.

By resetting the clock my photos presumably don't have a time zone offset and I'm safe. I think that option 5 on import does what I want (just in case I do have images with a time zone offset) but I then want IMatch to continue ignoring timezone offset altogether.

Presumably using UTC would mean that I would no longer need to enter a time offset when mapping GPS tracks (which seem to be UTC using the phone app I use) but that is something I'm used to doing and is a one-off when importing.

[novaca]

It is essential for me to have information about what time I took the picture at the given place. If I have a photo of the sunset in Hong Kong from 9:00 PM, I definitely don't want it to show that it was taken at 1:00 PM in my "resident zone". 
Also if I take a picture on August 1st (DST) of the church tower with the clock at 6:00 am, I want to still see in the metadata on December 1st that it was at 6:00 am and not changed by an hour... 
Yes if I took a picture during the hour when the time is moving, so there would be a mess. Or when taking pictures on a airplane while crossing time zones... However, I am willing to sacrifice these two cases and, if they occur, solve them "manually".

[Mario]

It is essential for me to have information about what time I took the picture at the given place. If I have a photo of the sunset in Hong Kong from 9:00 PM, I definitely don't want it to show that it was taken at 1:00 PM in my "resident zone". 

The File.DateTime is displayed in your local time-zone. This will not change.
To see the date and time the camera has recorded and the time-zone offset the camera has recorded right now, you can display the corresponding metadata tags instead.

The changes I'm introducing for IMatch 2023 for File.DateTime add a lot more flexibility. That's the reason why I'm doing it.

When calculating File.DateTime from a suitable metadata tags or the (as the last resort) last modified / created file system timestamp, IMatch also records the time-zone offset used when calculating the UTC timestamp.

For your first example, if your camera records a time of 10:00:00 and the Hong Kong time-zone offset of +08:00, IMatch sets File.DateTime to 02:00:00 and remembers the +08:00.
If you enter 10:00:00+08:00 in the Metadata Panel or via TimeWiz, IMatch performs the same calculation, setting File.DateTime to 02:00:00 and remembering the +08:00 offset.

When you display the file in the German time-zone (+01:00), the File Window Date & Time attribute displays 03:00:00. This attribute and the related Time attribute are in local time, always.

But what IMatch can do now, is to provide additional attributes, e.g. File.DateTime.UTC (02:00:00) or File.DateTime.Original, which would be 10:00:00 or 10:00:00+08:00 for full precision.

So, for the timestamp in your first example, we now can display the file time (for example, in the German +01:00 time-zone) as:

File.DateTime: 03:00:00 or 03:00:00+01:00
File.DateTime.UTC: 02:00:00
File.DateTime.Source: 10:00:00 or 10:00:00+08:00

This should cover all bases I guess.

[HaWo]

1) I need Local Time

2) I need only Local Time

3) I need no other times

Why all this times, when it us so complex?

But other user have other interests.

[Mario]

2) I need only Local Time

Different users have different needs. If you only take photos in your time-zone, nothing of this will matter to you and you don't need to do anything. If you travel a lot, things will look different.

When you take an image at 10:00:00 am in Hong Kong and later look at the image in Germany, what time should be displayed? Local time would be 03:00:00, UTC would be 02:00:00 and Hong Kong time would be 10:00:00...

The standard File.DateTime in IMatch was always created based on local time when the image was added to the database. So it was always frozen in that local time. And displayed as such.

The new File.DateTime is stored in UTC and converted into local time when used as before. No change there.
But IMatch can now can also, if a user desires, display the File.DateTime in UTC or in the time-zone the image was taken in. Before you had to resort to directly accessing metadata timestamps via tags to achieve that.

[Tveloso]

But IMatch can now can also, if a user desires, display the File.DateTime in UTC or in the time-zone the image was taken in. Before you had to resort to directly accessing metadata timestamps via tags to achieve that.

This might be the key for many users...for File.DateTime to display the time from the time-zone where the image was taken.

This gives us the dest of both worlds...the files still have the proper relative chronology (because File.DateTime is stored in UTC), but we can also see the "time value" from where the image was taken.

Excellent!

[Mario]

I agree.

I have added File Window Attributes (for File Window Layouts) like

Date & Time (same as before, local time)
Date & Time in UTC
Date & Time Original (calculated from UTC and the time-zone the image was taken in)
Date & Time Original  with time-zone offset

Time
Time in UTC
Time Original
Time Original with time-zone offset

Date
Date in UTC
Date Original

which checks all the boxes.
New variables which return the same information have been added too. This makes this available basically everywhere.

[monochrome]

I'd like to add for point 2.2 that the GPS Timestamp,

File.MD.XMP::exif\GPSTimeStamp\GPSDateTime\0

, if present, is guaranteed to be in UTC.

[Mario]

I'd like to add for point 2.2 that the GPS Timestamp,

File.MD.XMP::exif\GPSTimeStamp\GPSDateTime\0

, if present, is guaranteed to be in UTC.

This is one of the (many) fallback timestamps IMatch uses when looking for suitable timestamps in video files.
IMatch treats this as UTC and, if selected, copies it into File.DateTime and remembers the 00:00 offset.

All numeric timestamps in QuickTime are supposed to be UTC (but often aren't) and the textural timestamps should include a time-zone indicator (but often have none). Many devices write local time (since they don't know about the current time-zone) but don't indicate that anywhere...
Which are the reasons for the QuickTime-specific metadata options. Video is an even bigger mess than image metadata. Not just date and time.

[Asgard]

I am a bit late to the game but anyway...

I very much appreciate this change. I have had some issues with the file window ordering of files, which was rectified by ensuring that the "Date Subject Created" field included time zone information. I also had some issues with how time was displayed differently depending on when (during DST or not) I was browsing files - which however, was easy to fix by modifying the file window layout.

For now I just want to make sure that my effort with "Date Subject Created" will be retained after migration. I guess so, according to this B) alternative migration mode:

B) Looking at existing metadata (date subject created), which should always be filled and valid (it is filled by IMatch unless the user disables that explicitly). Or it has been filled by the user.
If this timestamp has no time-zone offset, IMatch would treat it as local time and calculate the UTC from it.

I haven't written back my changes to "Date Subject Created" everywhere, but I suppose that won't matter during migration. Am I right?

Also, I want to display my files in the file window ordered according to UTC time, and I want the local time and if possible the time zone + DST offset to show in the thumbnail. The first is a direct consequence of using UTC for all File.DateTime and I think the rest is covered by is covered by the added File Window Attributes that was mentioned in  post #28.

Finally I was wondering about the DST. Is that information ever given in a separate metadata field, or is it always baked into the timezone? Should the timezone offset metadata e.g. EXIFTimeZoneOffset tag include DST?

Best wishes for the work with the new major version!

[Mario]

I haven't written back my changes to "Date Subject Created" everywhere, but I suppose that won't matter during migration. Am I right?

Migration uses the database contents, not file contents.
If the date subject created has a time-zone offset (ideal case) it will be used to calculate the File.DateTime in UTC from it.
DST is not stored anywhere in metadata. No indicator.

When IMatch 2023 converts from UTC into local time, it considers the DST setting at that UTC time.
Windows has a functions which use the standard time zone database to figure out if DST was on or of in the local time zone for any given UTC time.

IMatch 2023 offers UTC time, local time, the time-zone offset used to calculate the UTC time (from the time-zone offset in date subject created, the local time-zone or the user-defined time-zone) etc. so users can, if so desired, construct their very own time display for File Windows and whatever other feature.

Not many users out there have a use for more than local time, though.

[akirot]

Haven't reread al posts, hope you are using all the "correct" tags.
We discussed this in November:

https://www.photools.com/community/index.php/topic,11048.msg90385.html#msg90385

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

Please keep in mind: "EXIFTimeZoneOffset" is a bit outdated; better are:
- OffsetTime (for ModifyDate)
- OffsetTimeOriginal (for DateTimeOriginal)
- OffsetTimeDigitized

These should precede TimeZoneOffset when present.

(Saying this: all my images contain OffsetTimes - a UTC calculation should be straight forward.)

To me Phil Harvey's (exiftool) page provides a perfect reference to all known tags.

Just because GPSDateTime has been mentioned in this context: GPSDateTime by definition always is in UTC. (Also to be precise: it's the timestamp of the GPSData NOT necessarily totally identical to the time the photo was taken.)

[HaWo]

My post is in wrong Thread, please excuse me

https://www.photools.com/community/index.php/topic,12964.0.html