Don't change File.DateTime due to DST in the "same TimeZone"

[Tveloso]

When the Apply time-zone option, in the XMP Import section, in Edit->Preferences->Metadata 2 is set to Yes, IMatch will create a value for File.DateTime in the user's "home TimeZone", if different from that in Date Subject Created.  Unfortunately, IMatch does this also when the UTC Offset in DateCreated differs from the current one, only due to DST.

For example, if we take a photo a few days before the end of DST, and then don't index that file until DST has ended, the value shown in File.DateTime will be one hour earlier than the value shown in Date Subject Created.  Likewise, if today (in December), we update a file that was originally indexed back in July, when the File is read back in, following the writeback, the value in File.DateTime (which was established when the file was originally indexed) will be changed to one hour earlier.

As discussed in this topic:

    https://www.photools.com/community/index.php/topic,12880.msg91132/topicseen.html#msg91132

...Javascript has the ability to determine when DST was in effect in a given TimeZone, and it will return the correct UTC Offset for dates in and out of DST (i.e. it adjusts the local timezone's UTC Offset based on whether or not DST was in effect).  If IMatch were to do that same thing, then File.DateTime would not change to an incorrect value when a file is added or updated during a different DST state from the one the File was created in.

For example, on a PC with a current UTC Offset of +1, IMatch would actually use +2 as the "local UTC Offset" when comparing to the UTC Offset in a file from July in that same TimeZone (and it would find both UTC Offsets to be the same, so no need to change File.DateTime)

Or maybe IMatch loads the File's TimeStamp into a Date Object, and the Object then emits its value in the Local TimeZone (already adjusted for DST), and that becomes File.DateTime.

I imagine that JavaScript might not be available to the "core IMatch code" that does this work though, but perhaps similar functionality is available there?

[Mario]

File.DateTime is in local time. IMatch derives it from the date subject created, applying the EXIF timezone in the file when reported by the device and finally converts it into a local time-zone timestamp using Windows routines (no JavaScript).

It is unknown to IMatch and irrelevant for most parts if the time-zone offset in the XMP or other timestamp is valid, where the image was taken or if DST is currently in effect or not. Or if DST was in affect when the image was taken or if the device considered that when setting the EXIF time-zone offset. Often time-zone offsets are not available at all (all files not having EXIF time-zone or maybe QuickTime time-zone tags), so this is all a bit of guesswork.

IMatch just needs a simple timestamp to have something that exists for all files, is fast to use for sorting etc. IMatch does this since version 3.

When I understand you correctly, you want IMatch to somehow figure out if DST was active at the time the image was created and then, depending on whether or not DST is currently active and thus will be applied by the routines IMatch uses, correct the File.DateTime by +- 1 hour during ingest?
To determine if DST was in affect when the image was taken, the location where the image was taken should be considered too. Because, not all countries use DST, so IMatch's guess might be wrong. Or IMatch could assume the image was taken in the same DST area as the computer is currently in? Complicated.

A solved feature request for IMatch 2023 was to add a user-defined time-zone offset to be included when calculating the File.DateTime from XMP date subject created, XMP date subject created time-zone offset and local time zone (+DST when active). But that would not solve your particular DST on/off problem.

I have never considered the current implementation to be a problem. You can always configure IMatch to display the original EXIF/XMP timestamps, with or without the time-zone offset recorded in the file. You can adjust timestamps using the TimeWiz.

I'm sure I could somehow figure out how to determine if DST was active when the image was taken and where the image was taken (maybe via a cloud service or some hard-coded tables). And then apply this.

Or I could switch File.DateTime to be in UTC (during an initial migration step when opening the database) and then convert File.DateTime into local time whenever it is needed. That would also mean that the date and time shown in the FW and elsewhere and variables and IMWS endpoints produce different values from one day to the other when DST is activated or deactivated. Windows does that with file timestamps, which is always a bit of fun.

This is certainly all doable. I just wonder if it would be really worth the development time? Or how urgent this really is for users.

[Tveloso]

When I understand you correctly, you want IMatch to somehow figure out if DST was active at the time the image was created and then, depending on whether or not DST is currently active and thus will be applied by the routines IMatch uses, correct the File.DateTime by +- 1 hour during ingest?
To determine if DST was in affect when the image was taken, the location where the image was taken should be considered too. Because, not all countries use DST, so IMatch's guess might be wrong. Or IMatch could assume the image was taken in the same DST area as the computer is currently in? Complicated.

I was thinking that it's really just the "local UTC Offset" that needs to be "re-evaluated" to see if it was different (due to DST) on the date the photo was taken.

The photo contains a fixed UTC Offset, and it (maybe) doesn't really matter whether or not that offset was impacted by DST.  If the current UTC Offset in our PC differs from that, but did not differ on the date of the Photo, then File.DateTime can contain the "observed" Date and Time in DateCreated.

I became excited when I saw that JavaScript takes care of returning the appropriate UTC Offset for a given Date/Time when converting a UTC TimeStamp.  So even though the current UTC Offset in my PC is -5, -4 is returned for Summer Dates...so this code:

Code Select Expand

var sumrDate = new Date("2022-07-21T15:00:00.123Z");
var wntrDate = new Date("2022-12-21T15:00:00.123Z");

console.log(sumrDate.toString());
console.log(wntrDate.toString());

...returns this on my PC:

    Thu Jul 21 2022 11:00:00 GMT-0400 (Eastern Daylight Time)
    Wed Dec 21 2022 10:00:00 GMT-0500 (Eastern Standard Time)
    (it even names "the TimeZone" that was resolved-to!).

So I thought that perhaps this "Date Technology" might also exist in the language/environment that IMatch is developed in, and it would make it easy for IMatch to do something similar.

But I'm very much speaking out of ignorance...and making guesses.

Or I could switch File.DateTime to be in UTC (during an initial migration step when opening the database) and then convert File.DateTime into local time whenever it is needed. That would also mean that the date and time shown in the FW and elsewhere and variables and IMWS endpoints produce different values from one day to the other when DST is activated or deactivated. Windows does that with file timestamps, which is always a bit of fun.

That sounds like it could be a good solution as well...(but maybe more involved?)

This is certainly all doable. I just wonder if it would be really worth the development time? Or how urgent this really is for users.

IMatch already provides options to address the DST thing (with a new one coming), so it's certainly not urgent.

I guess we'll see if there are any other users who would find this a worthwhile change.

Mario, thank you so much for creating IMatch - its just an extraordinary piece of Software.  Happy Christmas to you and your family!