P: Save Metadata To File incorrectly changes .CR3 when there are no changes to the photo

[johnrellis]

When the catalog setting Write Date Or Time Changes Into Proprietary Raw Files is enabled, Save Metadata To File will incorrectly modify a .CR3, changing its EXIF:DateTimeOriginal.

This bug was introduced in LR 14.4 -- it doesn't occur in LR 14.3. Tested on Mac OS 15.5. To reproduce:

1. Download and open this very small catalog:

https://www.dropbox.com/scl/fi/q8h2ewc5tf3snplofz1j8/raw-capture-time.2025-06-29.zip?rlkey=nggfak157...

Observe that the Metadata panel shows the .CR3 has Capture Date/Time: 6/29/25 1:26:10 PM.

2. Open the "pics" subfolder in the catalog folder in Finder with View > As List. Sort the view by Date Modified. Take note of the Date Modified for the .ARW and .CR3.

3. Select both photos and do Metadata > Save Metadata To File. Observe in Finder that the Date Modified of the two files hasn't changed and that there are now two .xmp sidecars (correct).

4. Set the option Catalog Settings > Metadata > Write Date Or Time Changes Into Proprietary Raw Files.

5. Do Metadata > Save Metadata To File again. Observe that the .CR3's Date Modified has changed to "now" (incorrect).

6. Remove the .CR3 from the catalog but not disk; delete its .xmp from the "pics" folder.

7. In the Folders panel, right-click "pics" and do Synchronize Folder to reimport the .CR3. Observe that the Capture Date/Time in the Metadata panel has changed from its original in step 1 (incorrect).  

Diffing the output from Exiftool shows that step 5 incorrectly changed the EXIF:DateTimeOriginal, EXIF:ModifyDate, and EXIF:CreateDate of the .CR3:

$ diff before.txt after.txt 
...
467c467
< [EXIF]          Modify Date                     : 2025:06:29 13:26:10
---
> [EXIF]          Modify Date                     : 2025:06:29 20:26:10
477,478c477,478
< [EXIF]          Date/Time Original              : 2025:06:29 13:26:10
< [EXIF]          Create Date                     : 2025:06:29 13:26:10
---
> [EXIF]          Date/Time Original              : 2025:06:29 20:26:10
> [EXIF]          Create Date                     : 2025:06:29 20:26:10

In this case, the new (incorrect) DateTimeOriginal has been shifted by +7 hours, corresponding to my time zone of UTC-7.

[Rikk Flohr: Photography]

@johnrellis 

The team has not been able to reproduce this via your instructions. Can you still reproduce the failure?
If you can, can you record your screen as you reproduce for our Dev to review?

[johnrellis]

@Rikk Flohr: Photography, I tested the recipe just now and it gave the same results. Here's a screen recording:

https://www.dropbox.com/scl/fi/dxz0oy0xch7tu4ytp5wvd/raw-capture-time.2025-06-29.mp4?rlkey=qt2gv60hr... 

Also, here's the original report from another user:

https://community.adobe.com/t5/lightroom-classic-discussions/lightroom-classic-14-4-changing-capture...

[Rikk Flohr: Photography]

Thanks @johnrellis  I will attach the video to the bug.

[Joe-P]

I have the same "problem" with CR2 files taken with Canon 6D - using LR 14.4.

Saving metadata "touches" some - but by far not all (I see no pattern) CR2 files without changing their content (checksums confirm unchanged CR2 file content).

In Windows (11) file explorer, "Date Modified" changes.

Remark: I did not adjust any capture time in LR - this would be written to CR2 - but this does not apply to my images.

[Rikk Flohr: Photography]

Greetings all, 

A new update for the Adobe Photography products has been released.  The August update contains an update regarding this issue. 

If you do not see the update in your Creative Cloud Application, you can refresh it by pressing  [Ctrl/Cmd]+[Alt/Opt]+[ R ].

Note: It may take up to 24 hours for your update to be available in your Creative Cloud app.

Thank you for being so patient. 

[Joe-P]

Thanks for the update to LR 14.5.

We'll observe whether it helps.

I am still disappointed that it does not help for a bug that is open since April:
https://community.adobe.com/t5/lightroom-classic-discussions/local-adjustment-settings-not-remembere...

[johnrellis]

I verified that the bug recipe now produces correct results, thanks.