Odd behaviors entering "Date Subject Created"

[birdbrain]

For some old scanned photos I have, I don't know the year - just that it is from the 1960s. So for "Date Subject Created", I have been entering: 1960:01:01 00:00:00.  I have learned that entering the time is required (even if 00:00:00).

When I do this the date display correctly (for the US) as 1/1/1960 12:00:00AM.

But later some of these photos show 1/1/960 12:00:00AM+19:00 in the metadata panel and 12/31/1959 1:00AM in the thumbnail.  (See attachment).  Note that this issue can happen, even when I know a specific date (like April 14 1963).

Then I noticed in help ("Working with Uncertain Dates" https://www.photools.com/help/imatch/#uncertain_dates.htm) that one should enter dates in the format yyyy-mm-dd hh:mm:ss.  So I thought: perhaps using a colon when I should have entered a hypen is the issue.

I went back, changed the dates using the format yyyy-mm-dd hh:mm:ss, then save the dates using the green check. If I go back into the "Date Subject Created" field just to peek, the display changes from m/d/yyyy to yyyy-mm-dd.  So far so good.

But after saving the metadata back to the file, if I "take a peek" at the date, the display changes from m/d/yyyy to yyyy:mm:dd.

So 2 things:

1. At least I know why I began to enter dates with colons: that's how IMatch shows the dates after saving metadata to file.  It's inconsistent with before saving metadata to file, but at least I now know this idiosyncrasy.

2. I am not confident that if I enter a date that it will "stick".  Were dates/times changed to 12/31/1959 +19hr because I entered the dates incorrectly?  Or is something else going on?  This is critical for old photos.

[Mario]

The YYYY-MM-DD was a typo in the help. IMatch and ExifTool always use the standardized ISO format internally for data exchange. I have corrected that.

I have never seen a timestamp I enter in the MD panel not stick (provided that the correct format is used when I manually enter a date): YYYY:MM:DD HH:MM:SS
As I said in your other thread about the same issue, the time must be set as well.
IMatch 2021 will set the time to 00:00:00 when the user does not enter it.

[birdbrain]

The YYYY-MM-DD was a typo in the help. IMatch and ExifTool always use the standardized ISO format internally for data exchange. I have corrected that.

Thank you as always for your response and for correcting the help.

So I assume this means I should ENTER dates as yyyy:mm:dd hh:mm:ss (and optionally TZ), correct?

I ask because the internal format doesn't really matter to me; what matters is how to enter dates.

I have never seen a timestamp I enter in the MD panel not stick (provided that the correct format is used when I manually enter a date): YYYY:MM:DD HH:MM:SS
As I said in your other thread about the same issue, the time must be set as well.
IMatch 2021 will set the time to 00:00:00 when the user does not enter it.

Yes, since our other thread(s), I have been careful to always enter 00:00:00 for the time, although no TZ offset. But these behaviors happen anyway, i.e., changing to prior date with +19.
I will try entering different times (e.g. 12:00:00) to see if that helps.
I also checked that IPTC & EXIF time zone settings in preferences were both blank, not accidentally set.

[Mario]

When you use the Date selector, it wills in the correct date in the correct format.
When you click into a date field, IMatch displays the native format, not your local format.
I have no idea why IMatch may shift the time by 19 hours. Do you live in a +19:00 hours time-zone? I mean, since you enter no time-zone offset, IMatch assumes that the date and time you enter is in your local time-zone.

[birdbrain]

When you click into a date field, IMatch displays the native format, not your local format.

This aligns with my experience.  In the metadata panel, I see native US format (m/d/yyyy hh:mm:ss xM). Once I click into the field, then yyyy:mm:dd hh:mm:ss appears (I assume this means "native" format).  All good.

Do you live in a +19:00 hours time-zone? I mean, since you enter no time-zone offset, IMatch assumes that the date and time you enter is in your local time-zone.

My time zone is US Eastern / GMT-5.  Perhaps -5-19 = -24 is clue (?)

I have no idea why IMatch may shift the time by 19 hours.

If I helps...I added some date fields to my metadata panel; see attached example. Also I would be glad to privately send you this file or other examples.

Apologies that I keep asking for help with this date thing.  I know you appreciate its importance for scanned photos.

I admit, I have not tested this by entering via the thesaurus or md template. I would assume the same issue would happen, as it appears later, after saving metadata back to the file. During field entry everything seems to work OK.

[Mario]

If this happens with a specific file and is reproducible:

a) Run the Metadata Analyst on that file and check if it reports any problems.
If it does, use the GREEN button at the top to copy the errors and warnings into the clipboard and paste below.

b) Send me the file to support email address - with a LINK back to this topic. Allow a week or more for a response, I'm always flooded with "on my PC and with my files, this and that does not work with metadata" and it always costs a lot of time to figure out what the problem is (if any) and explain how to fix it.

[birdbrain]

Info sent.
Thank you.

[Mario]

I have looked at the file. As expected, a bit of metadata mess.
The file shows in ECP:


[IPTC]          Date Created                    : 1960:01:01
[IPTC]          Time Created                    : 00:00:00+19:00
[IPTC]          Digital Creation Date           : 1960:01:01
[IPTC]          Digital Creation Time           : 00:00:00+00:00

After IMatch has fixed the problem:


[IPTC]          Date Created                    : 1960:01:01
[IPTC]          Time Created                    : 00:00:00+00:00
[IPTC]          Digital Creation Date           : 1960:01:01
[IPTC]          Digital Creation Time           : 00:00:00+00:00

The important bit is th legacy IPTC timestamp which includes a 19 hour offset.
The [XMP-photoshop] mirrors this because they are mapped.

I solved this problem by setting both (!) timestamps (date created and date subject created) to the date and time I wanted. Ensuring that both timestamps show as modified (pen icon in front).
Both timestamps must be in the state "modified". If you don't want to change the time, click the pen icon in front of the tag to mark it as modified.
Then write-back. IMatch synchronizes the timestamps across XMP and EXIF and IPTC. No problems at all.

There are often issues with files containing legacy IPTC (declared legacy almost 20 years ago), EXIF and XMP and maybe different time-zone offsets in all of them.
Setting the two timestamps correctly once in the IMatch MD panel (ensuring that they show as modified and are written back) fixes this.
Also, consider removing the legacy IPTC data from your files (ECP preset) to avoid such issues. XMP is way better.

[birdbrain]

First of all, thank you for taking time to analyze the file and the issues. Had to read through your response a few times but I think I get it now.

I guess I want IMatch do the work and not have to think about IPTC vs XMP, ExifTool/ECP, etc.  But also know that is not how IMatch works; it is highly configurable.  But I think I know enough to configure it (or automate it) to clean up incoming data and make my workflow smoother once in IMatch and think less. 

Thanks again!

[Mario]

The problem is not IMatch or how configurable it is.
The problem in this case is that your file contains disagreeing timestamps for the same values.

There are two timestamps IMatch is interested in (there are dozens others, depending on the file format you use and the metadata it contains).
To make things even more funny for the end-user, different applications name these timestamps differently. Not even Adobe uses the same terms across their applications.
See How IMatch uses Date and Time Information

"Date created" / (digitized) and "Date subject created" (which is the more important, real date). You can have a photo from 1920 (date subject created) that was digitized (scanned) in 2020.
IMatch uses EXIF timestamps by default. But if a file contains legacy IPTC metadata (as in your case), these human-edited (!) timestamps have priority.

Which is why the +19 hours IPTC timestamp overrides things. And when you don't let IMatch update both timestamps during write back (you change only one timestamp), it does not update the corresponding XMP tag during write-back, which then does not repair the incorrect IPTC timestamp.

My tip to change both timestamps (or at least mark them as changed by clicking the pen icon in front) causes both XMP timestamps to be written, properly replacing the wrong IPTC timestamp. After IMatch could synchronize everything, you're good.

Normal folks edit their files with all kinds of applications, without knowing if and how these applications write metadata. And, usually, such problems are not uncovered unless the user switches to another application or has to deliver files to a client or agency or web site. This is not an old problem. Even current popular applications produce crap when it comes to write metadata - like only writing minimal XMP records (basically only the tags they allow users to edit), not mapping legacy IPTC/EXIF/GPS as required etc. This is a metadata mess in waiting and there will be tears in a few years. But their marketing is good and so...

[jch2103]

I can only repeat what Mario says. Date/time metadata is a mess, especially when you've edited metadata with multiple programs in the past. Dealing with scanned images further complicates the issue (because of usually missing/incomplete dates).

Simplifying the amount of metadata you deal with is usually a good idea, particularly getting rid of Classic IPTC data. It certainly made things easier for me.

[birdbrain]

The problem is not IMatch or how configurable it is.
The problem in this case is that your file contains disagreeing timestamps for the same values.

I did not mean to imply IMatch is/was a problem.

I also understood from your earlier post I need to change both dates.

[Mario]

The problem is not IMatch or how configurable it is.
The problem in this case is that your file contains disagreeing timestamps for the same values.

I did not mean to imply IMatch is/was a problem.

I also understood from your earlier post I need to change both dates.

Yes, changing both dates, or marking them as changed, will make IMatch write-back both timestamps. This allows it to synchronize EXIF, legacy IPTC and XMP timestamps in your files, fixing the mess creating by some other application.

[lbo]

The YYYY-MM-DD was a typo in the help. IMatch and ExifTool always use the standardized ISO format internally for data exchange. I have corrected that.

ISO 8601 is YYYY-MM-DD, used in also in XMP

YYYY:MM:DD is the EXIF time format, not ISO.

I think the IMatch help should stay with (revert to) ISO 8601.

ISO 8601 is the universal, unambiguous time/date format to be used by anybody.

BTW, Wkipedia tells me that the initial release of the EXIF standard was 1995, and ISO 8601 was first published in 1988. I wonder why they invented yet another time format then.

Sorry for the gripe, but I can get so worked up about stupid date formats. There shall be only one time/date format!

[Mario]

I believe ExifTool handles both YYYY-MM-DD and YYYY:MM:DD. At least in my limited test.
If you input a date as YYYY-MM-DD HH:MM:SS in the MD Panel, it should write back just fine.
It delivers dates to IMatch as YYYY:MM:DD.

[birdbrain]

Have been on holiday and just getting back to this headache...

I solved this problem by setting both (!) timestamps (date created and date subject created) to the date and time I wanted.
Setting the two timestamps correctly once in the IMatch MD panel (ensuring that they show as modified and are written back) fixes this.

To be sure we are 100% clear: What are the exact names of the two fields that need to be entered?

I assume "date subject created" is {File.MD.XMP::photoshop\DateCreated\DateCreated\0}

For "date created" (IPTC), is it
  {File.MD.Composite\IPTC-DigitalCreationDateTime\DigitalCreationDateTime\0}
or
  {File.MD.Composite\IPTC-DateTimeCreated\DateTimeCreated\0}
?

Note that I cannot enter either of these fields in the metadata panel. They have lock icons next to them.

Also, consider removing the legacy IPTC data from your files (ECP preset) to avoid such issues. XMP is way better.

I will certainly consider "removing the legacy IPTC data" if that will make life better.  But what does this mean?  How do I do it safely, i.e., not screw up something in my metadata?  What is "ECP preset"?

Normal folks edit their files with all kinds of applications...

Sorry that I am not "normal"  But I really don't care about IPTC, XMP, ABC, DEF, or XYZ as, for example, professionals might.  I use one tool only (IMatch).  I want enter the date the photo was originally taken and have IMatch do the rest. Since IMatch will not do this "out of the box", I recognize I will have to build metadata templates, use manual workarounds, etc.  But then I can use IMatch to browse and search my photos, i.e, my real goal.

[Mario]

The two dates shown in the Default layout in the Metadata Panel.
To delete legacy IPTC data from files, run the "Delete legacy IPTC data" preset in the The ExifTool Command Processor

[jch2103]

@birdbrain - Note that for scanned images, you are likely to want to distinguish between the original photo date/time and the scanned date/time. That's something I didn't do with some of my early scans, but wish I had.

[birdbrain]

My tip to change both timestamps (or at least mark them as changed by clicking the pen icon in front) causes both XMP timestamps to be written, properly replacing the wrong IPTC timestamp. After IMatch could synchronize everything, you're good.

To delete legacy IPTC data from files, run the "Delete legacy IPTC data" preset in the The ExifTool Command Processor

As suggested, I deleted the legacy IPTC data, entered BOTH dates, confirmed the metadata (green check), then wrote it back to the file. So far so good.
I then entered a location in the metadata panel and confirmed it. Still OK.
But when I save back to the file, BOTH dates change.  This time "+20:00" was added.

So it may be that some other "fossil" data is interfering(?)  Regardless, I have a theory:

Nearly all of my photos are right from a camera, iPhone, or scanner and never imported to a DAM or other tool.  But a very small number (much less than 5%) have been "touched" by Mylio and had sidecar XMP files.

I have imported JPGs "touched" by Mylio along with sidecars.  (I then delete the sidecars).

But I have also imported JPGs "touched" by Mylio, and imported WITHOUT sidecars. 

I entered locations for JPGs where I never provided a sidecar to Imatch and these seem OK.  The dates do not change.

I cannot say I tested this thoroughly.  So my plan is to delete all my IMatch folders and start over -- this time never importing with the sidecars.

If this does not work, I will post for more help.

Thank you.

[Mario]

Your local time-zone is?

I have imported JPGs "touched" by Mylio along with sidecars.  (I then delete the sidecars).

Allowing Mylio to touch metadata pretty much voids all kind of support from my side.
Mylio does very strange things to metadata. I would not let it come near any of my files.
Did you contact Mylio support and asked for advice?

Usually, the best thing would be to provide sample images, check these files with the The Metadata Analyst, post the results etc.
I believe that you see strange things happening with the metadata in your files.
But it would be a waste of your time, and mine, to try to guess what the metadata mess is you are in.
I have spent way too much time analyzing metadata problems caused by cameras, other software and user workflows.

[birdbrain]

Usually, the best thing would be to provide sample images, check these files with the The Metadata Analyst, post the results etc.
I believe that you see strange things happening with the metadata in your files.
But it would be a waste of your time, and mine, to try to guess what the metadata mess is you are in.
I have spent way too much time analyzing metadata problems caused by cameras, other software and user workflows.
[/quote]

I have already sent samples to you, which was helpful. I have also made progress (I think!) on my own.

Rather than specific support, I have a general question:

Based on your recommendations I do the following:
- Run "Delete legacy IPTC (IIM) metadata" in the Exif tool processor.
- Enter both "Date Subject Created" and "Create Date". (I enter time of 12:00:00 as they are pre-digital / scanned images.)

I then used the MD panel to examine all the date fields and discover:

- Photos with issues have dates / times in these variables, with "+19:00" added.
Date/Time Created {File.MD.Composite\IPTC-DateTimeCreated\DateTimeCreated\0}
Digital Creation Date {File.MD.Composite\IPTC-DigitalCreationDateTime\DigitalCreationDateTime\0}
Time Created {File.MD.IPTC::ApplicationRecord\60\TimeCreated\0}

- Photos without issues those variables are blank.

When I write metadata back to the file, "+19:00" is added to "good" fields like "Date Subject Created", perhaps "infected" by the 3 variables above.

My only question: Is there a way to erase those 3 fields?

Thank you!
Joe

[Mario]

IMatch interprets time-zone offsets during import. Newer EXIF data has optional time-zone offsets for create date and date subject created.
You can see these offsets in the ExifTool Command Processor: Run the "List Metadata" and then search for offset.

When you remove the +19:00 time-zone offset in the MD panel and write-back, IMatch sets XMP and EXIF and also removes the time-zones from the EXIF record.
Instead of manually removing the time-zone offset you can use the Time Wiz to remove them.

I don't recall you sending me images, but I handle 50 emails per day and many users send me many things.
Without seeing the metadata in your file or the MD Analyst results, there is not much else I can do.

[birdbrain]

When you remove the +19:00 time-zone offset in the MD panel and write-back, IMatch sets XMP and EXIF and also removes the time-zones from the EXIF record.

I have been able to easily remove the "+19" offset for "Date Subject Created" and "Create Date", whether using MD panel or TimeWiz.

I cannot remove "+19" for these as they are locked in the MD panel:

   Date/Time Created {File.MD.Composite\IPTC-DateTimeCreated\DateTimeCreated\0}
   Digital Creation Date {File.MD.Composite\IPTC-DigitalCreationDateTime\DigitalCreationDateTime\0}
   Time Created {File.MD.IPTC::ApplicationRecord\60\TimeCreated\0}

And I suspect that, because they retain the "+19", it is somehow being applied to "Date Subject Created" and "Create Date" when writing metadata to the file.  If that is impossible, my theory is wrong.
[/quote]

[Mario]

Metadata tags which are synchronized with XMP metadata are locked - because your manual changes would be overwritten during write-back.
Setting create date and date subject created in the MD panel is all that is needed - if that fails, the metadata in your file is messed up and without a sample and the MDA report, nothing further can be done.

[birdbrain]

Setting create date and date subject created in the MD panel is all that is needed - if that fails, the metadata in your file is messed up and without a sample and the MDA report, nothing further can be done.

I have already sent samples and MDA report. You suggested that I run "Delete legacy IPTC (IIM) metadata" in the Exif tool processor, which I done.

So there no way for IMatch to accept what I enter (or TimeWiz) into create date and date subject created and leave it be?  Is there a possible setting I am missing?

Metadata tags which are synchronized with XMP metadata are locked - because your manual changes would be overwritten during write-back.

Yes, what I enter for create date and date subject created are being overwritten by IMatch.

[Mario]

Attach a sample image which produces the problem or send it to support email address with a link back to this thread.
Deleting the legacy IPTC data works in 99% of all cases, by experience.
If you are working with RAW files, check the MDA for messages about conflicting embedded XMP and sidecar XMP.

I have already sent samples and MDA report. Y

I handle about 350 emails per week. Plus this community.
I don't even know the email address you have used or if you have sent your files a week ago or 3 months ago.
You need to give me some more details.

[birdbrain]

I mentioned sending examples earlier and you said

I handle about 350 emails per week. Plus this community.
I don't even know the email address you have used or if you have sent your files a week ago or 3 months ago.
You need to give me some more details.

I would prefer to learn how to fish, instead of having you give me a fish.  Better for me, less work for you. 

So I believe I have solved the issue.

Recap:

For some files, when I enter Create Date and Date Subject Created, sometimes "+19:00" is added after writing MD to file.

You suggested deleting the legacy IPTC data, which I have done, but it didn't help.

I noticed these variables (which are meaningless to me) have the dates/times that I enter, but always keep "+19:00" added.

   Date/Time Created {File.MD.Composite\IPTC-DateTimeCreated\DateTimeCreated\0}
   Digital Creation Date {File.MD.Composite\IPTC-DigitalCreationDateTime\DigitalCreationDateTime\0}
   Time Created {File.MD.IPTC::ApplicationRecord\60\TimeCreated\0}

Also noticed

- If I enter Create Date and Date Subject Created;   Save to file;   Everything is OK

- If I change something else (headline, rating, etc.);  Save to file;  IMatch adds "+19:00" to Create Date and Date Subject Created.

Which is rather confusing: the issue occurs when changing something other than the dates.

The fix:

I used the batch processor (first time for me) and created a preset that keeps the image exactly as is and only copies: "XMP: All Data" and "EXIF Camera Info: All data (including GPS data)".

Everything works perfectly with the output file. The "+19:00" never appears and these (useless) dates remain empty:

   Date/Time Created {File.MD.Composite\IPTC-DateTimeCreated\DateTimeCreated\0}
   Digital Creation Date {File.MD.Composite\IPTC-DigitalCreationDateTime\DigitalCreationDateTime\0}
   Time Created {File.MD.IPTC::ApplicationRecord\60\TimeCreated\0}

Attach a sample image which produces the problem or send it to support email address with a link back to this thread.

Have emailed the before and after batch processing versions, along with their MDA files.  Images were too large to post.

[Mario]

Did you check the files in the ExifTool Command Processor? The time-zone offset must come from somewhere. IMatch does not add time-zone offsets by itself.

[Mario]

The original file you have sent contains:


[ExifIFD]       Date/Time Original              : 1949:01:01 12:00:00
[ExifIFD]       Offset Time                     : -04:00
[XMP-exif]      Date/Time Original              : 1949:01:01 12:00:00
[IPTC]          Time Created                    : 12:00:00+19:00
[IPTC]          Digital Creation Time           : 12:00:00+19:00


IPTC days: This data has a time-zone offset of +19:00 hours.
EXIF says: This data has a time-zone offset of -4:00 hours.
You can't have both, obviously.

In my first attempt, I set the date created / date subject created in the MD panel to 12:11:10 and write back.
The file now contains:


[ExifIFD]       Date/Time Original              : 1949:01:01 12:11:10
[ExifIFD]       Offset Time                     : +02:00
[XMP-exif]      Date/Time Original              : 1949:01:01 12:11:10
[IPTC]          Time Created                    : 12:11:10+25:00
[IPTC]          Digital Creation Time           : 12:11:10+25:00


My local time-zone is GMT+02:00 so that's what's now written (correctly) into EXIF Offset.
The IPTC time-zone offset was shifted to +25:00 hours...
19 + 6... - while we have -04:00 in the original EXIF plus 02:00.
Not sure what ExifTool is doing here. And I don't think it's worth time figuring out.

So, I've made my wishes explicit by setting the two timestamps in the MD panel to 12:11:10+02:00, explicitly stating the time-zone offset.
Now the file contains


[ExifIFD]       Date/Time Original              : 1949:01:01 12:11:10
[ExifIFD]       Offset Time                     : +02:00
[ExifIFD]       Offset Time Original            : +02:00
[ExifIFD]       Offset Time Digitized           : +02:00
[XMP-exif]      Date/Time Original              : 1949:01:01 12:11:10+02:00
[IPTC]          Time Created                    : 12:11:10+02:00
[IPTC]          Digital Creation Time           : 12:11:10+02:00


and all timestamps and time-zone offsets agree. Even the legacy IPTC data retired 20 years ago.

[birdbrain]

So, I've made my wishes explicit by setting the two timestamps in the MD panel to 12:11:10+02:00, explicitly stating the time-zone offset.

...all timestamps and time-zone offsets agree.

I seems you are suggesting to always add time-zone offset, or at least when IPTC times are wrong.

I tried this and it worked. FYI, if I go back and remove the time-zone offset, then +19:00 returns.

With this suggestion, I will consider an MD Template to do clean-up rather than Batch processing.

...all timestamps and time-zone offsets agree. Even the legacy IPTC data retired 20 years ago.

Not sure what ExifTool is doing here. And I don't think it's worth time figuring out.

I have some thoughts on this but will take time to write it properly/effectively as a feature request.

[Mario]

I tried this and it worked. FYI, if I go back and remove the time-zone offset, then +19:00 returns.

How can that be. There should be nothing in the file that has a time-zone offset of 19 hours. Unless your local time-zone is +19:00.
After I updates your example image with the timestamps as described, the only occurrences of 19 are



Where should the 19 hour time-zone offset come from?

[birdbrain]

I agree and will post a "feature request" regarding this topic.
Thank you,
Joe

[PandDLong]

I have been following this with interest.

I have one question from this earlier post:

Based on your recommendations I do the following:
- Run "Delete legacy IPTC (IIM) metadata" in the Exif tool processor.
- Enter both "Date Subject Created" and "Create Date". (I enter time of 12:00:00 as they are pre-digital / scanned images.)

I then used the MD panel to examine all the date fields and discover:

- Photos with issues have dates / times in these variables, with "+19:00" added.
Date/Time Created {File.MD.Composite\IPTC-DateTimeCreated\DateTimeCreated\0}
Digital Creation Date {File.MD.Composite\IPTC-DigitalCreationDateTime\DigitalCreationDateTime\0}
Time Created {File.MD.IPTC::ApplicationRecord\60\TimeCreated\0}

Aren't those three "problem" fields legacy IPTC metadata - ie. shouldn't they have been deleted?

Michael

[birdbrain]

This is the jist of my "forthcoming" feature request:

If these fields are legacy "garbage", why are they in IMatch at all and potentially allow them to "infect" other data?

I assume there is some rationale, but I would propose: Whenever a customer takes the time to manually enter the date the photo was taken (Data Subject Created) it should NEVER change, period. This should be true of any data element. Whenever any software changes data without the user's knowledge/consent, it violates the integrity of the data and the customer's trust in the software is diminished.

From other parts of the conversation, I infer this may be due to exiftool. But that would seem to mean IMatch prioritizes a design principle of separation of IM and exiftool over a design principle of maintaining integrity of customers' data.

So now I guess I have essentially stated my "feature request", but will do so more clearly in the proper forum place.

[Mario]

If these fields are legacy "garbage", why are they in IMatch at all and potentially allow them to "infect" other data?

As per Metadata Working Group standards and recommendations and because this is a living industry standard.
Legacy IPTC data in files must be maintained and updated.
Despite having been deprecated 20 years ago, many companies, image agencies, news outlets, web sites etc. rely on legacy IIM IPTC metadata.

IMatch follows the rules. It does not create legacy IPTC data, but it updates it when it exists.

Usually this makes not that many problems.
Unless users have mistreated their files with all kinds of shitty software which updates XMP and/or IPTC only, or partially or did some other half-assed thing.
When a user has legacy IPTC data in his/her files, he/she probably has a reason.

If you don't want the IPTC data in your files anymore, the ExifTool Command Processor in IMatch has a preset to delete it.

[PandDLong]

I understand the rationale as to why iMatch needs to support the legacy data - ie. if it already exists, update it.  The software can't know if it is needed for the user's workflow or not. 

As that legacy data seems to create issues and problems, could there be an iMatch Metadata preference to delete this data on indexing to make it even more "out of the box" rather than running ECP for all those users who don't need it?


My question was that in the post of August 15th, Joe stated he had run the ECP preset to delete legacy data but it looks like it was still in the files - that is how I read his post.   I was trying to understand how that could be as the legacy data seems to be the source of his issue and he thought he had deleted it.

Michael

[Mario]

I'm not keen on adding features to IMatch which automatically delete potentially important data.
Besides, IMatch uses legacy IPTC to fill XMP data on import, like it does use EXIF, GPS and existing IPTC.

This is way less of a problem that an user who was just burned by problematic legacy IPTC data in some of his files.
Pretty much this depend on how badly the metadata in the files was treated before. If you use an Adobe workflow you won't notice many, if at all, problems.
If you try different software on your files, you may damage the metadata badly. This not only includes legacy or hobby-level software but also current popular products, which aim more for shiny than solid.

If the IPTC data in your files is causing problems, make an informed decision and then run the preset in the ECP.
I have never experienced the legacy IPTC data in a file surviving an explicit deletion run of ExifTool.
Unless the file was badly corrupted, but then the ECP will present you with corresponding error messages.

[PandDLong]

I seems you are suggesting to always add time-zone offset, or at least when IPTC times are wrong.

I tried this and it worked. FYI, if I go back and remove the time-zone offset, then +19:00 returns.

Sorry for jumping into this thread but your experience of metadata changes "disappearing" was also a recent experience of mine that I think I figured out and now have a workflow that works.   I agree with you that one wants to be confident that changes you make to the data "stick" - unfortunately metadata is tricky at times.  In my experience this is particularly true if the change you want to make is to delete a piece of data.

IMHO the +19:00 is coming back from a tag that you aren't updating and when the metadata is readback after being written, ExifTool doesn't see any time zone in the main tags and thinks "it is missing" and thus grabs the one time zone it finds in the file from some obscure tag.   Really it should be thinking that no time zone is valid data so don't go find one from an obscure tag - but that is not how it works.

Before you get the +19:00 coming back - can you see what tag(s) still have that time zone in them?

Michael

[Mario]

As I explained above, the only 19 in the entire file after the correction in IMatch is the 19th century.
No other 19 found anywhere, just in the year of the dates.

[PandDLong]

Sorry Mario.  I should have been clear - I was asking Joe as he is having a different experience.

Michael

[birdbrain]

Michael

Sorry for the delayed response and thank you for jumping in. Always good when users can share experiences, questions, and comments directly.

Will try to address your points individually:

My question was that in the post of August 15th, Joe stated he had run the ECP preset to delete legacy data but it looks like it was still in the files - that is how I read his post.   I was trying to understand how that could be as the legacy data seems to be the source of his issue and he thought he had deleted it.

IMHO the +19:00 is coming back from a tag that you aren't updating and when the metadata is readback after being written, ExifTool doesn't see any time zone in the main tags and thinks "it is missing" and thus grabs the one time zone it finds in the file from some obscure tag.   Really it should be thinking that no time zone is valid data so don't go find one from an obscure tag - but that is not how it works.

Before you get the +19:00 coming back - can you see what tag(s) still have that time zone in them?

These tags had +19:00 in them, and yes, I am not updating them because they are locked. The only dates I enter are Date Subject Created and Create Date.

Date/Time Created {File.MD.Composite\IPTC-DateTimeCreated\DateTimeCreated\0}
Digital Creation Date {File.MD.Composite\IPTC-DigitalCreationDateTime\DigitalCreationDateTime\0}
Time Created {File.MD.IPTC::ApplicationRecord\60\TimeCreated\0}

You are correct: Using a suggestion from Mario, I ran the ECP Preset "Delete legacy IPTC (IIM) metadata".  It did not remove these variables.

Mario then provided a tip to manually add time zone (-4:00) to Date Subject Created. This does replace the "+19:00" with "-4:00" in those 3 "bogus" variables. If I then try to delete the "-4:00" from Date Subject Created, the "+19:00" reappears in those 3 variables.

If this all has something to do with Exiftool then, IMO: If it is internally used by IMatch, it shouldn't matter to me, an IMatch customer. I bought IMatch, not Exiftool.

...your experience of metadata changes "disappearing" was also a recent experience of mine that I think I figured out and now have a workflow that works.

Would appreciate any tips about your workflow that deals with this.

I am trying to come up with techniques to deal with these issues: 1. The "+19:00 bug" I'll call it, where legacy / useless variables infect "good" variables; 2, The need to enter the date taken twice (Data Subject Created and Create Date).  I am working on some metadata templates to do this as that should be more reliable than manually entry.

I understand the rationale as to why iMatch needs to support the legacy data - ie. if it already exists, update it.  The software can't know if it is needed for the user's workflow or not. 

As that legacy data seems to create issues and problems, could there be an iMatch Metadata preference to delete this data on indexing to make it even more "out of the box" rather than running ECP for all those users who don't need it?

I could not agree more. By analogy, if I use financial software and manually enter a check for 6 May 2021, that software should NEVER say "I know better" and change the date without informing me. It should do everything it can to preserve the integrity of the data.  In the photo context, I simply want to enter the basics ("who/what/where/when/why") and trust the software to maintain what I enter and hope it will make things easier than using Windows Explorer.

This issue particularly insidious because (a) IMatch does not state that it changed the date, (b) the change does not appear immediately, (c) if I enter dates, they look fine but if I change something else later on (e.g. headline) the "+19:00" appears, (d) the issue appears when saving back to the file (even more bizarre).  It is only after much experience and very carefully looking that I discovered all this.

[Mario]

These variables reflect XMP data, not legacy IPTC data. They will not change after you have removed the legacy IPTC data. Did you verify the result of your operation?

The sample file you have provided does NOWHERE contain anything that would cause the 19:00 hour offset.
I and a test users have checked that the suggested workflow of removing the legacy IPTC data (which has the 19:00 time-zone offset) does indeed fix the problem.
Or actually setting a time-zone offset as described above by me.
You can always see the data your file contains in the ECP.

This has nothing to do with ExifTool (which is used by IMatch for VERY GOOD REASONS - because it is the gold standard for metadata handling) nor with IMatch.
If the metadata mess in your files is not fixed after you have closely followed my working and verified instructions above, send the very SAME FILE you have used for that TEST to my support email support email address

I find it more than puzzling that the sample file you have provided some weeks ago and which worked just fine for me and a test user after applying my steps does not work on your system. I don't recall a similar support case.
I'm not sure what else I can do about this. I have already invested a lot of time (aka cost) into this by answering your questions, testing your file, analyzing the problem, writing a report about the results and providing working and verified steps to solve the issue.