[BBD] File.DateTime departs from Date Subject Created with external update/re-import

[Tveloso]

This seems somewhat similar to this old bug report:

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

...but the circumstances under which it happens are very different, and this one is reproducible.

I have some old scans, that were originally indexed under IMatch 2023.  They contained no valid Dates, so IMatch had to fall back to using the FileSystem TimeStamps.  An approximate Date was later manually entered for XMP::photoshop\DateCreated\DateCreated\0.

When one of these files is externally modified, and IMatch re-imports the file, the value in File.DateTime is changed to today's date, while XMP::photoshop\DateCreated\DateCreated\0 retains its manually entered value (so the two now disagree).

For example, a file that physically contains only these FileSystem Dates:

Code Select Expand

[System]            - File Modification Date/Time     : 2024:05:15 20:42:08-04:00
[System]            - File Access Date/Time           : 2024:05:16 11:21:52-04:00
[System]            - File Creation Date/Time         : 2024:05:15 20:42:56-04:00

...had a date of 1 May 1984 manually entered in Date Subject Created:

   

...which is pending to be written-back, and File.DateTime currently agrees with that Date value:

   

When I click on the Favorite to open that File in Photoshop:

   

...apply a slight crop there, and save the file back out, PS adds some Modify Dates into the File (and replaces all three FileSystem TimeStamps), but retains the old "Date Digitized":

Code Select Expand

[System]            - File Modification Date/Time     : 2025:02:28 09:17:02-05:00
[System]            - File Access Date/Time           : 2025:02:28 09:17:30-05:00
[System]            - File Creation Date/Time         : 2025:02:28 09:17:02-05:00
[IFD0]            306 Modify Date                     : 2025:02:28 09:17:02
[XMP-xmp]           - Create Date                     : 2024:05:15 20:42:56-04:00
[XMP-xmp]           - Modify Date                     : 2025:02:28 09:17:02-05:00
[XMP-xmp]           - Metadata Date                   : 2025:02:28 09:17:02-05:00

When IMatch then re-imports that file, the value in Date Subject Created is still correct:

   

...but File.DateTime has now changed to today's Date (presumably from Modify TimeStamp?):

   

[Mario]

Did you write back before opening the file in Photoshop? That is unclear but very important.
Which metadata protection settings are enabled under Edit > Preferences > Metadata 2?
Show a link to the file modified by Photoshop or at least the values of these variables:

Code Select Expand

DT: {File.DateTime}
DT: {File.DateTime.TZO}
UTC: {File.DateTime.UTC}
LT: {File.DateTime.Local}
LT: {File.DateTime.Local.TZO}
Org: {File.DateTime.Original}
Org: {File.DateTime.Original.TZO}

[Tveloso]

No, the file was not written back before opening in PhotoShop.

I must leave for a bit, but I'll do this with another file, and will include the additional information.  I also recorded a debug log during this first test, and can send that if needed.

[Mario]

Then metadata protection kicked in, probably.
You have missing time stamps, you create them in XMP only but not write back.
File is modified in other software, IMatch reloads the file. Now we have probably a mix of whatever.

Try the same but first write back the time stamps IMatch has created after you have set the two XMP timestamps in the MD panel. Then open in Ps and see what this changes.

[Tveloso]

I fully expected that if the file was written-back before being updated in PS, that this issue would not manifest, and that was in fact the case.

I did this with two files, writing back one of them first.  As expected, the manually entered Date Subject Created was retained as the value for File.DateTime in the first one, after an update in PS, but the second one (while also retaining its value in Date Subject Created), had its File.DateTime changed to depart from that.

So File-1 looked like this in the MD Panel:

   

...and File.DateTime was:

Code Select Expand

DT . . : 5/1/1984 12:00:00 AM
DT . . : 5/1/1984 12:00:00 AM-04:00
UTC  . : 5/1/1984 4:00:00 AM
LT . . : 5/1/1984 12:00:00 AM
LT . . : 5/1/1984 12:00:00 AM-04:00
Org  . : 5/1/1984 12:00:00 AM
Org  . : 5/1/1984 12:00:00 AM-04:00

The File actually contained only FileSystem TimeStamps:

Code Select Expand

[System]            - File Modification Date/Time     : 2024:05:15 20:47:44-04:00
[System]            - File Access Date/Time           : 2024:05:16 11:21:54-04:00
[System]            - File Creation Date/Time         : 2024:05:15 20:48:33-04:00

Prior to being updated in PS, this file was written-back, and then contained a full compliment of proper Dates:

Code Select Expand

[System]            - File Modification Date/Time     : 2025:02:28 15:06:56-05:00
[System]            - File Access Date/Time           : 2025:02:28 15:06:58-05:00
[System]            - File Creation Date/Time         : 2024:05:15 20:48:33-04:00
[IFD0]            306 Modify Date                     : 2025:02:28 15:06:55
[XMP-exif]          - Date/Time Original              : 1984:05:01 00:00:00-04:00
[XMP-photoshop]     - Date Created                    : 1984:05:01 00:00:00-04:00
[XMP-xmp]           - Create Date                     : 2024:05:15 20:47:44-04:00
[XMP-xmp]           - Metadata Date                   : 2025:02:28 15:06:55-05:00
[XMP-xmp]           - Modify Date                     : 2025:02:28 15:06:55-05:00
[ExifIFD]       36867 Date/Time Original              : 1984:05:01 00:00:00
[ExifIFD]       36868 Create Date                     : 2024:05:15 20:47:44
[Composite]         - Create Date                     : 2024:05:15 20:47:44-04:00
[Composite]         - Date/Time Original              : 1984:05:01 00:00:00-04:00
[Composite]         - Modify Date                     : 2025:02:28 15:06:55-05:00

After being re-imported, it looked like this in the MD Panel:

   

...and File.DateTime was unchanged:

Code Select Expand

DT . . : 5/1/1984 12:00:00 AM
DT . . : 5/1/1984 12:00:00 AM-04:00
UTC  . : 5/1/1984 4:00:00 AM
LT . . : 5/1/1984 12:00:00 AM
LT . . : 5/1/1984 12:00:00 AM-04:00
Org  . : 5/1/1984 12:00:00 AM
Org  . : 5/1/1984 12:00:00 AM-04:00

But File-2, which looked like this:

   

...and likewise contained only FileSystem Dates:

Code Select Expand

[System]            - File Modification Date/Time     : 2024:05:15 20:48:32-04:00
[System]            - File Access Date/Time           : 2024:05:16 11:21:55-04:00
[System]            - File Creation Date/Time         : 2024:05:15 20:48:33-04:00

...and had this in File.DateTime:

Code Select Expand

DT . . : 5/1/1984 12:00:00 AM
DT . . : 5/1/1984 12:00:00 AM-04:00
UTC  . : 5/1/1984 4:00:00 AM
LT . . : 5/1/1984 12:00:00 AM
LT . . : 5/1/1984 12:00:00 AM-04:00
Org  . : 5/1/1984 12:00:00 AM
Org  . : 5/1/1984 12:00:00 AM-04:00

...once updated in PS, and re-imported, still held the correct Date Subject Created):

   

...but its File.DateTime became this:

Code Select Expand

DT . . : 2/28/2025 3:11:58 PM
DT . . : 2/28/2025 3:11:58 PM-05:00
UTC  . : 2/28/2025 8:11:58 PM
LT . . : 2/28/2025 3:11:58 PM
LT . . : 2/28/2025 3:11:58 PM-05:00
Org  . : 2/28/2025 3:11:58 PM
Org  . : 2/28/2025 3:11:58 PM-05:00

I was just thinking that this might be somehow related to that old bug report.

Even though it's really apples and oranges here, since this involves an external update, and a re-import, while that other (much more elusive) bug involved an IMatch-only manipulation (with the "bad value" for File.DateTime coming from one of the files in a multi-file selection), since the end result was the same (a value in File.DateTime disagreeing with the File's Date Subject Created, I thought there could perhaps be some correlation.

But of course, there have also been a great many changes in IMatch since then (most notably in IMatch 2023's treatment of File.DateTime), so that old bug could very well have been eradicated as part of those changes.

I know I saw that issue at least once after we had that discussion though (not sure in which IMatch version it was), and just like in the original Bug Report, I could not reproduce it afterwards (so didn't report it again).

[Mario]

Is there any action item for me still?

If you change metadata in IMatch but don't write back before manipulating metadata in the same image in some other application, the out come is somewhat fuzzy and depends on the metadata protection settings enabled and which metadata the other application has created, removed or modified.

[Tveloso]

No action item Mario.

It makes perfect sense that causing a re-import, for a file that's currently in a Writeback Pending state (by updating it externally), is a bit fuzzy.

This just reminded me of that other bug report (which I thought could potentially still be lurking), so I thought I should report it.

I'm good with knowing that I should write-back first, before sending a file to Photoshop.