Problem with write back CreateDate to XMP file after importing NEF file

[baardman]

Last week I upgraded to the latest version of IMatch. Now I've issues writing back pending data to a XMP file after importing NEF files. I've tested on JPG and CR2 files and there's no issue.

After writing back all pending data the XMP::\xmp\CreateDate keeps the status pending. When I go to Edit Menu > Preferences > Metadata 2 and change Date and Time > Mark file as pending write-back to off, the issue is not there.

I don't know why I've this problem with only NEF files. It always worked perfectly. Furthermore I don't know if the real solution is changing the preferences. I just use the default settings.

[Mario]

The preferences are set to Mark as pending for good reasons.
IMatch produces "date subject created" and "create date" from the metadata found in the file as explained in How IMatch uses Date and Time Information

If this creates "new" time stamps, they are marked as pending, so you know.
I have never seen a pending "coming back" because of a date and time. The usual reason are out-of-sync keywords in legacy IPTC / XMP / hierarchical keywords.

We need more info about the NEF file and the XMP.
Please ZIP and upload to your cloud space and post a link.
Or send an email with the link to support email address with a link back to this thread.

Maybe ExifTool cannot write the XMP and NEF file?
Did you check the IMatch log files for warnings (search for W> to find them).

You might also want to run the Metadata Analyst on the NEF to see if it has metadata problems.
See The Metadata Analyst

Use the GREEN button in the Metadata Analyst to copy the result into the clipboard and then paste them into your reply.

[baardman]

I imported a new NEF file and before the write back command I ran Metadata Analyst.

-------------

Metadata Analyst Results. Version 2023.2.4. 20-8-2023 18:37:51
File analyzed: H:\Foto werkruimte\Foto 2023\Nieuwe map\NZ7_0701.NEF
Errors: 0
Warnings: 18

Warning: [System] File has unwritten metadata (pending write-back).<br/>The metadata loaded from the image and the data in the database may not match.
Warning: [GPS] Date missing.
Warning: [GPS] Time missing.
Warning: [GPS] Latitude missing.
Warning: [GPS] Latitude Ref missing.
Warning: [GPS] Longitude missing.
Warning: [GPS] Longitude Ref missing.
Warning: [GPS] Altitude missing.
Warning: [XMP] [ExifIFD]:DateTimeOriginal not mapped to [XMP-exif]:DateTimeOriginal (embedded).
Warning: [XMP] [ExifIFD]:DateTimeOriginal not mapped to [XMP-photoshop]:DateCreated (embedded).
Warning: [XMP] [IFD0]:Copyright not mapped to [XMP-dc]:Rights (embedded).
Warning: [XMP] [IFD0]:Artist not mapped to [XMP-dc]:Creator (embedded).
Warning: [XMP] [IFD0]:Artist not mapped to [XMP-tiff]:Artist (embedded).
Warning: [XMP] [IFD0]:Orientation not mapped to [XMP-tiff]:Orientation (embedded).
Warning: [XMP] [ExifIFD]:UserComment not mapped to [XMP-dc]:Description (embedded).
Warning: [Detailed Validation] [minor] Non-standard SubIFD1 tag 0xc7d5 NikonNEFInfo
Warning: [Detailed Validation] [minor] Unknown SubIFD1 tag 0xc7d6
Warning: [Detailed Validation] Wrong IFD for 0x9003 DateTimeOriginal (should be ExifIFD not IFD0)

[baardman]

After write back I ran Metadata Analyst again
------------------

Metadata Analyst Results. Version 2023.2.4. 20-8-2023 18:39:12
File analyzed: H:\Foto werkruimte\Foto 2023\Nieuwe map\NZ7_0701.NEF
Errors: 0
Warnings: 20

Warning: [System] File has unwritten metadata (pending write-back).<br/>The metadata loaded from the image and the data in the database may not match.
Warning: [GPS] Date missing.
Warning: [GPS] Time missing.
Warning: [GPS] Latitude missing.
Warning: [GPS] Latitude Ref missing.
Warning: [GPS] Longitude missing.
Warning: [GPS] Longitude Ref missing.
Warning: [GPS] Altitude missing.
Warning: [XMP] Embedded XMP record (NIKON Z 7 Ver.03.60    ) and XMP sidecar file (Ver.03.60) found.
Warning: [XMP] Embedded XMP rating is 0.
Warning: [XMP] [ExifIFD]:DateTimeOriginal not mapped to [XMP-exif]:DateTimeOriginal (embedded).
Warning: [XMP] [ExifIFD]:DateTimeOriginal not mapped to [XMP-photoshop]:DateCreated (embedded).
Warning: [XMP] [IFD0]:Copyright not mapped to [XMP-dc]:Rights (embedded).
Warning: [XMP] [IFD0]:Artist not mapped to [XMP-dc]:Creator (embedded).
Warning: [XMP] [IFD0]:Artist not mapped to [XMP-tiff]:Artist (embedded).
Warning: [XMP] [IFD0]:Orientation not mapped to [XMP-tiff]:Orientation (embedded).
Warning: [XMP] [ExifIFD]:UserComment not mapped to [XMP-dc]:Description (embedded).
Warning: [XMP] [ExifIFD]:UserComment not mapped to [XMP-dc]:Description (sidecar).
Warning: [Detailed Validation] [minor] Non-standard SubIFD1 tag 0xc7d5 NikonNEFInfo
Warning: [Detailed Validation] [minor] Unknown SubIFD1 tag 0xc7d6

[baardman]

Did you check the IMatch log files for warnings (search for W> to find them).

I changed the log to Debug, before importing and writing back. There are no warnings

[baardman]

I mailed you a link to the NEF+XMP

[Luckyman]

Hi, exactly the same problem here with the .NEF files I imported today after updating to 23.2.4  Tomorrow I will have more time to investigate this issue.

[Mario]

The problem seems to be an embedded XMP record in the NEF file.
IMatch does not update it (RAW files use XMP in sidecar files).

Usually not a problem since Nikon/Canon only create an incomplete and rudimentary XMP record in the NEF/CR*, containing maybe a hard-coded rating=none and some fluff.

If they decided to add date and time to the NEF file, this produces two sources of truth for these time stamps - which is not good.

Delete the XMP record in the NEF using the ExifTool Command Processor (there is a preset for that) and then try again.

[baardman]

When I delete the XMP record via the ExifTool there is no issue anymore.I don't know what the effect of this action is when I process the NEF file in for example NXstudio.

I understand what you write, but I don't understand why it has become an issue now. I didn't have this issue with the NEF files from the same camera and older camera's in previous releases of IMatch. 

[Mario]

This sounds like the XMP record in the image had 'colliding' date information...?
IMatch maintains XMP files for RAW files only in sidecar files, but during import, merges XMP data found in the image with XMP data found in the XMP sidecar file - giving priority to metadata embedded in the image.

So far, the only problem caused by camera vendors was the embedding of a hard-coded rating=None in the RAW image. Which IMatch by default ignores so the actual rating in the XMP sidecar file takes precedence.

If Nikon devices (or the software you use to work with the NEF files) started to embed more XMP in the RAW file, things will have to change. Camera vendors are notorious for producing rather sub-standard software and for breaking established rules and standards at a whim - like suddenly encrypting white balance metadata, their undocumented and ever changing RAW formats, crappy metadata management, undocumented binary maker notes and whatnot.

I have never had a problem with NEF files that matches your experience, and I have tons of them.
But I have never used NXstudio, though. Maybe that software is the culprit?

I was burned by Nikon-made software in the past, so I don't use software from Nikon anymore.
Their old software had severe problems with metadata, when I recall correctly, so I wonder...

I will know more when I've had a look at your sample NEF file.

Since my "My metadata does not work correctly, my image does not load, ... please analyze this file!" email queue is always full, it may take a couple of days or up to two weeks to look into this.

[Luckyman]

Hi Mario,

I would like to emphasize that the described error occurs exactly in the same way on my system. I copied the .NEF files from SD-card to my harddrive and imported the folder in IMatch 2023.2.4. I never used any software from Nikon to process my images.

The camera is a Nikon D7500 with the latest firmware 1.11. Before updating to IMatch 2023.2.4, I imported thousands of .NEF-files from this camera in the same way. There had never been a write-back error for 'CreateDate'! Nikon has not changed the camera firmware since June 2022.

I'm waiting for a solution because this issue causes a couple of problems, e.g. when I use the command 'write back all pending metadata'. Maybe I have to re-import all files after you fixed this bug?

[baardman]

Hi Mario,

To prevent mistakes. I don't use NX studio, but I don't know what the implications are outside IMatch when you remove the xmp record. I usually use Photoshop. In my workflow I always import the NEF files in IMatch prior to any image processing.

I have not experienced problems with the NEF files from the same camera before. I also tried it with NEF files from older cameras and they now also give problems. So I don't think it's related to new RAW formats.

I will wait for your analysis.

[Luckyman]

The bug in the new program version worries me a lot. Also older, existing .NEF-files are affected by the CreateDate write back error   This afternoon I made some further tests:

1. I opened a folder with .NEF-files I had imported two weeks ago, using IMatch 2023.1.22.
2. All files were already tagged and metadata was written in .XMP sidecar files.
3. The files DID NOT show a marking for 'pending metadata write back' (no pencil)
4. I changed the rating of a single .NEF-file – a marking for 'pending metadata write back' (pencil) appeared as I expected.
5. I clicked the pencil symbol for metadata write back – the .XMP sidecar file was written in approx. 2 seconds.
6. The pencil disappeared only for the fraction of a second and popped up again! CreateDate is marked as 'write back pending'

[jch2103]

This afternoon I made some further tests:

1. I opened a folder with .NEF-files I had imported two weeks ago, using IMatch 2023.1.22.
2. All files were already tagged and metadata was written in .XMP sidecar files.
3. The files DID NOT show a marking for 'pending metadata write back' (no pencil)
4. I changed the rating of a single .NEF-file – a marking for 'pending metadata write back' (pencil) appeared as I expected.
5. I clicked the pencil symbol for metadata write back – the .XMP sidecar file was written in approx. 2 seconds.
6. The pencil disappeared only for the fraction of a second and popped up again! CreateDate is marked as 'write back pending'

I just tried this test with some NEF files I'd added a month ago. I have the latest firmware update installed for my Z6. At least in my installation, once the write back occurred the pencil didn't return. 

[sinus]

I just tried exactly this with the newest version 2023.2.4.

I have only Nefs from a D750 Nikon.
One I tried from Juni 2022, the other from february 2023 ... both no problem. 

The pencil was vanished, came not back.

[Mario]

Thanks for sending the NEF file. I have analyzed the problem and here are my findings.

The NEF file contains a rudimentary XMP record.
And it contains one of the standard XMP time stamps:

[XMP-xmp] Create Date : 2023:08:20 12:21:40.67

This is the first time I see this. Usually Nikon only messes things up by placing a hard-coded Rating=None in the embedded XMP record.

The problem is that:

a) the time stamp exists in the XMP
b) it is also wrong
c) also, the second required XMP time stamp is missing, but that's just a minor issue.

The XMP time stamp written by Nikon is wrong because the EXIF record of this file shows these time zone offsets in the EXIF metadata:

[ExifIFD] Offset Time Original : +02:00
[ExifIFD] Offset Time Digitized : +02:00

which need to be applied when creating XMP data from EXIF time stamps.
The time stamp Nikon should have written to the XMP is therefore:

[XMP-xmp] Create Date : 2023:08:20 12:21:40.67+02:00 

but they did not. Why? Bug? Carelessness? Nikon metadata mess again? I don't know.

And this causes a problem for IMatch.

IMatch reads the metadata from the NEF and gets an XMP timestamp. This takes priority over the time stamp that might exist in the XMP (embedded data is prioritized).

IMatch sees the Create Date in XMP has no time-zone offset and adds the correct offset by applying the EXIF time zone offset found in the file: 2023:08:20 12:21:40.67 => 2023:08:20 12:21:40.67+02:00.

This is what shows in the Metadata Panel.
And since IMatch has modified the imported Create Date timestamp, it marks it as modified and the file gets the pending write-back icon.

When you write back, IMatch writes XMP metadata to the XMP sidecar file (where XMP data should be stored for RAW files, according to XMP and industry practice).

The XMP file then contains the correct time stamps with the correct time zone offsets, matching the EXIF time stamps in the NEF and the EXIF time zone offsets in the NEF:

[XMP-photoshop] Date Created : 2023:08:20 12:21:40.67+02:00
[XMP-xmp] Create Date : 2023:08:20 12:21:40.67+02:00

After ExifTool has updated the XMP file (no data is written to the NEF because only XMP data was changed), IMatch rereads the NEF and XMP file to import all changes ExifTool has made (time stamps, check sums, mapped tags etc.).

And, again, IMatch gets the Create Date time stamp from the NEF because it prioritizes embedded XMP over sidecar XMP.
And the same play starts all over again. The Create Date has no time zone offset, IMatch adds it and marks the Create Date tag as modified.

This is the "complete" XMP record Nikon has stored in your file:

Code Select Expand

[XMP-xmp]      Creator Tool                    : NIKON Z 7 Ver.03.60
[XMP-xmp]      Create Date                    : 2023:08:20 12:21:40.67
[XMP-xmp]      Rating                          : 0
[XMP-crd]      Exposure 2012                  : 0.00
[XMP-crd]      Highlights 2012                : 0
[XMP-crd]      Shadows 2012                    : 0
[XMP-crd]      Luminance Smoothing            : 0
[XMP-crd]      Luminance Noise Reduction Detail: 75
[XMP-crd]      Luminance Noise Reduction Contrast: 0
[XMP-crd]      Color Noise Reduction          : 7
[XMP-crd]      Color Noise Reduction Detail    : 50
[XMP-crd]      Color Noise Reduction Smoothness: 50
[XMP-crd]      Sharpness                      : 48
[XMP-crd]      Sharpen Radius                  : 2.00
[XMP-crd]      Sharpen Detail                  : 25
[XMP-crd]      Sharpen Edge Masking            : 0
[XMP-crd]      Contrast 2012                  : -6
[XMP-crd]      Saturation                      : 2
[XMP-crd]      Camera Profile                  : Camera Standard
They did not bother to create the required XMP-exif tags from the EXIF in the file, added only one time stamp, and that is wrong etc. Stupid.

Solution to your Problem:

I have none, except for deleting the embedded XMP metadata or the invalid time stamp at least.
Please contact your Nikon support team and ask them to fix this bug in their firmware.
They might listen or just laugh in your face.

For the future of IMatch, I might add some special override code like for the hard-coded Rating=None or I might abandon the "embedded XMP is higher priority" for some file formats, while keeping it for file formats like JPG, TIFF.
I don't know yet.

If the Japanese camera vendors would just stick to the standards they helped writing and avoided all the half-assed and crappy metadata features they add to their firmware, all would work so well.

[Luckyman]

Hi Mario,

thank you for this detailed information. I see that Nikon does not stick to the standards and can understand your frustration.

But why did NEF-import work flawlessly before I updated to IMatch 2023.2.4? I guess it may be connected to bugfix #02011 (XMP Date & Time Import).

Why are jch2103 and sinus unable to reproduce this error?

[Mario]

But why did NEF-import work flawlessly before I updated to IMatch 2023.2.4? I guess it may be connected to bugfix #02011 (XMP Date & Time Import).

Probably.

Why are jch2103 and sinus unable to reproduce this error?

Different camera models and firmware.
As I said, I have never seen a NEF file where the camera added the XMP Create Date time stamp. This is new. And also buggy.
Let me know what Nikon tells you about this bug and if and when they intent to fix it.

[Luckyman]

I used Metadata++ to check some Nikon DSLRs for the XMP Basic schema (xmp-xmp), embedded in the NEF-files:

Nikon D2Xs - Not available
Nikon D7100 - Not available
Nikon D7500 - Embedded information found: CreateDate, CreatorTool, Rating

Obviously this problem only affects the latest Nikon DSLRs and Z-series.

[Mario]

I used Metadata++ to c

You can see this in IMatch as easily. Run the ExifTool Command Processor with the "List Metadata" preset.
Then search for XMP to see if and which XMP data your device has written.

The The Metadata Analyst emits a warning like
Embedded XMP record (NIKON Z 7 Ver.03.60 ) and XMP sidecar file (Ver.03.60) found.
when it detects both an embedded XMP record and a sidecar file.

As a work-around, you can configure IMatch to ignore the embedded XMP data in NEF files completely.

Edit > Preferences > Metadata 2: File Formats.
Scroll down until you see NEF and then set these settings:

[baardman]

Hi Mario,

Thank you for your analysis and explaination. I will have to do some more testing. I have this issue with NEF files from a Z7 and a D850. I will check with NEFs of other Nikon bodies.

The reason why it has become an issue now is possibly the bug fix which Luckyman referred to.

I understand your frustration of non-compliance by Nikon with industry standards. I can report it to Nikon, but the chances that they will come with firmware updates for older gear is nihil. I will check if it's also an issue with the newest camera's and report a bug in that context.

I would be happy with a kind of override or ignore option in IMatch. In the mean time I can look at the "remove xmp record" option. I know that Camera RAW reads more information from the NEFs from the mirrorless Nikon bodies. I don't know if it is the xmp-record information. I have to test that. The ideal situation would be a correction of the CreateDate in the xmp record in the NEF file or removal of this attribute. This last option must be done with the ExifTool if I'm correct. I'm not experienced in making scripts for this tool.

Is it possible to add a preset with the next IMatch release, like the "remove xmp record" preset?

[baardman]

While I was typing my reply you posted a workaround 👍😎

I will use the work around, but I'm also interrested in a ExifTool preset to remove the CreateDate. 

[Mario]

This should do the trick:

Code Select Expand

# im-warn
-overwrite_original_in_place
-xmp:createdate=
-charset
filename=UTF8
{Files}

I can report it to Nikon, but the chances that they will come with firmware updates for older gear is nihil.

That's how support is defined these days. As soon as a camera model is available for purchase, it is 2 generations out of date for the camera company. You want bug fixes? Buy a new camera.

I will check if it's also an issue with the newest camera's and report a bug in that context.

To Nikon, I hope.
Crappy metadata written by a camera or software is not an IMatch problem.

[baardman]

Thanks for the code.

I hear you regarding crappy metadata. I agree it's not an Imatch problem, but for me as a user it has become a problem. So I need a safe way to deal with the situation.

[Mario]

So I need a safe way to deal with the situation.

Use the setting I've described to force IMatch to ignore XMP metadata in NEF files.
No additional special cases needed. It's already built in.

[Luckyman]

Thank you Mario!

Your workaround looks like a perfekt solution for me. But if it is true that the latest Nikon DSLR bodies and all Nikon Z-bodies are affected, many IMatch users will face this issue sooner or later. Wouldn't it be better to set 'ignore XMP metadata in NEF files' as the new standard?

P.S.: I used Metadata++ to check my NEF files because IMatch wasn't available in the studio this morning. Thank you for the tip!

[Mario]

Wouldn't it be better to set 'ignore XMP metadata in NEF files' as the new standard?

What if the NEF file contains important but 'non-disturbing' metadata?
This data can be precious for many users and IMatch imports the data for good reasons. What if Nikon ads more metadata to the NEF in the future that is important to the user?

Why should I pile workaround on top of workaround in IMatch, while camera vendors continue to implement crappy island solutions, write or write not partial XMP records, store incomplete or plain wrong XMP metadata in the files?

Cameras you paid good money for, I believe.

Fixing metadata bugs should be as important for camera vendors as fixing bugs in image quality, wireless connections and whatnot. XMP is on the market for over 20 (!) years now. Nikon should long ago embraced it, fully and correctly. Not writing "some" XMP tags, depending on the camera model, firmware and moon phase.

I provided two solutions designed to deal with this Nikon BUG.

When other uses are affected (and giving the spread and overall quality of Nikon firmware, this might happen or not), I will tell them the same story- Nikon BUG. Nikon must FIX.

Here are the two ways to work around this Nikon BUG in IMatch.

Or I might just add yet another work-around bug list to the metadata config which holds more Nikon-specific problem items to deal with silently in the background. Like IMatch has so many already.
And I can tell you, I'm sick of all this metadata mess. So much of my precious life time wasted dealing with an ever-increasing pile of metadata mess camera and software vendors produce.

[twe]

I have no issues with NIKON Z6 Ver.03.50 and Imatch 2023.2.4. So not all Z-bodies are affected. 

[twe]

I have no issues with NIKON Z6 Ver.03.50 and Imatch 2023.2.4. So not all Z-bodies are affected.

Maybe I was too quick, no issues but found the Create Date . 

ECP: List Metadata (no create date)

[XMP-xmp]      Creator Tool                    : NIKON Z 6 Ver.03.50
[XMP-xmp]      Rating                          : 0

But from Exiftool standalone (exe file):

---- XMP-xmp ----
Creator Tool                    : NIKON Z 6 Ver.03.50
Create Date                    : 2023:08:03 10:46:54.44
Rating                          : 0

[Mario]

If ExifTool emits the XMP depends on how your query looks.
There should be no difference in out if the same arguments are used for the ECP and the command line.
IMatch just runs ExifTool, hands over the arguments in form of an ARGS file and displays the ExifTool output.

Having a Create Date in the embedded XMP record is not the problem.
The problem is that the XMP Create Date written by Nikon ignores the EXIF time zone offset written by Nikon into the same file!
And this is why IMatch produces a correct Create Date with the +02:00 time zone offset in the XMP, but that no longer matches the Create Date embedded in the XMP.

I think I will just extend / rename the "Ignore Rating in embedded XMP record" option (which is on by default) and also make it ignore XMP Create Date and Date Subject Created in embedded XMP records.
This will work around this Nikon BUG. At least until Nikon or Canon come up with other XMP atrocities.

[baardman]

I think I will just extend / rename the "Ignore Rating in embedded XMP record" option (which is on by default) and also make it ignore XMP Create Date and Date Subject Created in embedded XMP records.
This will work around this Nikon BUG. At least until Nikon or Canon come up with other XMP atrocities.

I sympathise with you and am also grateful for the work around   I understand this is not the way you want it.

I will contact Nikon Support Center and give it a try.

[baardman]

Hi Mario,

I've been reading all your replies again and How IMatch uses Date and Time Information.
I have also read the XMP standard on the Adobe site and I have access to ISO16684. I think this standard for Datatype Date is not flawless.

Adobe and ISO state:
"The time zone designator need not be present in XMP. When not present, the time zone is unknown, and an XMP processor should not assume anything about the missing time zone.
Local time-zone designators +hh:mm or -hh:mm should be used when possible instead of converting to UTC. "

I think it would be better that the time zone designator was mandatory or they used something like the EXIF standard. You are not assuming anything, because you can find the time zone in the EXIF data. When I look at the XMP sidecar after I opened a file in CameraRAW I see that Adobe comes with something like this: "xmp:CreateDate="2023-08-20T12:32:50.45+02:00". They also seem to look for a timezone and add it to the CreateDate. So nothing strange there.

Unless I'm missing something, Nikon is compliant with the XMP standard. However, I think they should have implemented it with the time zone designator and that's what I can report to Nikon Support Center.

Are my findings and conclusion correct or am I missing something? I'm trying to learn here and I want to make sure I don't get "you don't understand the standard" answer back from Nikon.

[Mario]

1. Nikon writes the EXIF time stamps with a +02:00 time zone offset.
2. Then they the same time stamp into XMP, but this time without a time zone offset, making it wrong by two hours.

I'd call this a bug.
All they need to to is to set the XMP create time to the same time as the EXIF create time.
By including the same time zone offset they add to the EXIF. Easy.

ExifTool does this.
Adobe products do this.
IMatch does this.

This particular problem seems to happen for your files only so far.
It has never been reported before, and I have quite a number of Nikon Z series NEF files in my test library.

Anyway, to stop wasting my time with analyzing, discussing and describing this problem and the consequences, I went ahead and created a solution for IMatch. I've had totally different plans for today, and now I've lost almost a full day on this new Nikon bug. Very expensive and my schedule is totally off now.

To deal with this new Nikon crap issue, I've changed the Ignore hard-coded Rating=None in RAW files option (which incidentally also was created to counteract Nikons stupid idea to add a hard-coded XMP rating = None to some of their RAW variants) to ignore the XMP create date in RAW files as well. This fixes this new Nikon foolery and should be good until the come up with new problems.

IMatch then just creates the XMP time stamps itself, using the existing EXIF data and time offset information when available. Else the mapping mode created by the user is applied.

And yes. Go and tell Nikon. Ask them why they record two different create date and time in your files.

This bug report is closed, since it is Nikon bug not an IMatch bug.

[Andreas]

Hi Mario,

I know you hate this topic, but I need to inform you that also Nikon D850 with newest firmware from beginning of this year (1.30) is affected.   Files were directly taken from camera memory card for testing, no transfer software involved.

FYI, I also recognized the same odd behavior of exiftool from user twe above:

If I use exiftool -s -f -G dsc_5239.nef as a command line, exiftool does not show the [XMP] CreateDate. 
However, if I use exiftool -s -f -G -xmp:all dsc_5239.nef, it does show  the [XMP] CreateDate.

(I know this does not help in any way resolving the issue, but I found it worth mentioning)

Bottom line, I'm afraid the need for hardcoded solutions on your end to fix NIKONs misbehaving firmware will not go away for quite some time...   If that helps you in any way, I can tell you that back in the 90s even microsoft hat to change its windows code to work around a hardware bug of a popular add-on-card (not sure if it was Sound Blaster or some SCSI card)... 

So, thanks for your flexibility and keep things up :-)

Andreas

[Mario]

The fix I've added should work for these files too.
I still recommend deleting the partial XMP record Nikon places in the NEF file and to have only one source of truth for XMP metadata for your RAW files (the sidecar).

Send me a sample image to support email address (photo of a wall will do just fine).

[GrantRobertson]

This message is in support of Mario. I have several different cameras (mostly old ones) from different brands. When I import images from those cameras, I first place them in separate folders, according to the brand and model of camera. This is because I know that each camera is going to do its own brand of stupidity to the files. I then work out a set of custom processing steps for each of those camera models. It may require a special trick for renaming files to my standard. Or it may require one or more custom EXIFtool scripts to clean up or fix some mess, before I add that file to my general population. I think of it as a quarantine process, of sorts.

These processes and scripts are completely unique to me, my workflow, and the cameras I use. Not only is it unreasonable to expect Mario to hard code a custom solution into the program to allow me to solve my unique problems by just checking yet another option in preferences - It is bad for the program. I have been in computing since 1976, and I have seen far too many good programs collapse under the weight of a thousand custom options. Sometimes, developers can be more accommodating than they should.

I know this issue appears to have been a bug in IMatch, because it only appeared after a certain update. But this can often mean that the program was simply ignoring flaws in the data up until the update. Oftentimes, cleaning up the code to more correctly handle data, can reveal these data flaws that had been long ignored. And this appears to be one of those cases. 

EXIFtool provides us the means to make very detailed corrections to the metadata in our image files. It is incredibly flexible and powerful. IMatch makes it easy for us to apply custom EXIFtool scripts to selected files. I know that learning EXIFtool can be a bit complicated. But no more complicated than learning color science or all the custom settings in our cameras. EXIFtool has great documentation and a great forum, where lots of people can help one learn. And many are willing to just write custom scripts for people out of the goodness of their hearts. Therefore, I think it is inappropriate for people to ask for custom, options in IMatch simply to avoid learning to use EXIFtool. 

[Mario]

The problem is caused the combination of 4 things:

1. IMatch detects and uses XMP data embedded in files, and merges them with XMP data found in the optional XMP sidecar files - giving XMP data embedded in the image a higher priority.

2. Nikon writing a partial XMP record into the NEF file.

3. Nikon writing a "create date" time stamp to XMP (new!) but also writing it wrong, because it does not match the EXIF timestamp of the same file. Since Nikon did not bother to include the time zone offset in the XMP, only in the EXIF.

4. IMatch, since version 2023, considering XMP time stamp without a time zone offset as not well defined.

4.1 A recent addition, to fix invalid metadata, as Grant points out, introduces this particular behavior with the invalid time stamp some Nikon images contain in their partial XMP record.

Nikon writes the "created" time stamp but it does not match the EXIF time stamp in the same file.
IMatch recognizes the incomplete created XMP time stamp on import (new!) and fixes it by adding the time zone from the EXIF record. The created time stamp in the database is now well-defined and correct.

When the user writes back, IMatch writes the updated and correct XMP time stamp into the XMP sidecar file.
It does not write XMP to the NEF RAW file. Which is the default for all RAW files.

Then it reads the XMP data from both the NEF file (which should not contain XMP data to start with) and merges it with the XMP data in the side car file to produce a "rich" and complete XMP record in the database.

This is where the process repeats. The XMP data in the NEF still contains the invalid created time stamp.
There should be never be two sources of truth for XMP. Either it should be embedded in the image or it should be in the sidecar file.

One solution would be to completely ignore XMP data in RAW files. But it might contain important data!
Or by default switch to always write XMP data into RAW files, breaking compatibility with other applications. Not good.
Or writing XMP in both the sidecar file and the RAW file. Two sources of truth again.
Or changing the priority from the embedded XMP record to the sidecar record - which would break handling for file formats which by default embed XMP metadata, like JPG, TIFF, PSD, PSB, DNG, PDF etc.
IMatch already has an option for this, but it should not be used by the general audience.

Or, Nikon just stops writing a a sub-standard and partial XMP record to some NEF variants, with an incorrect created date and a hard-coded rating=none.

I have fixed this for the next release by extending the existing work-around for the hard-coded "rating=none" seen in some RAW variants' XMP record. This work-around now also ignores the created and date subject created time stamps in embedded XMP records in RAW files. IMatch now prefers to generate these time stamps itself, from the EXIF data in the file, applying the correct time zone offset. This work-around is enabled by default.

I have been in computing since 1976, and I have seen far too many good programs collapse under the weight of a thousand custom options. Sometimes, developers can be more accommodating than they should.

I agree. I actually tend to remove options from IMatch, where applicable.

Many options have been hidden behind an expert mode in 2022  - which substantially reduces the numbers of options new users see. Existing users won't notice this, since expert mode is on by default for existing installations.
You can disable expert mode (recommended) under Edit > Preferences > Application.

The Edit > Preferences > Application dialog has an option to hide rarely used options. Which is on by default.
This has caused some support events, though, since users overlook this check box and wonder why they cannot find a specific setting. But it cleans up the dialog nicely and does not frighten new users

There is no golden way for all this.

Users manage images created over a time of 20, 30 or more years in IMatch.
From scanned slides over images from early DSLRs to RAW images produced by the latest generation of smart phones.
The images have been modified with a dozen or more different applications. And even "modern" software often produces a big metadata  mess - because doing metadata right is hard and binds precious developer resources.

And that's without camera vendors inventing new and buggy "things" for their RAW files, introducing breaking changes silently with firmware updates and the ever changing and undocumented RAW formats, which are such a joy...