P: Edit Capture Time displays times one hour earlier during daylight savings time

[scottf1931000]

Hello: I just updated to the 15.0 release and I think I just discovered a bug. When I click Edit Capture Time via the Metadata tab, whatever time I enter is one hour off from the time that shows up in the EXIF data panel (and how it sorts the photo if "Capture Time" is used to sort the library); therefore to get the EXIF information to show up correctly, I must purposely enter the information one hour behind the time I want it to be (see screenshot where I want 5:31pm to be the edited time, but I must enter 4:31pm to get 5:31pm).  -- Scott, MacBook Pro, Apple M3 Pro chip, macOS Sequoia 15.6.1.

[Bob Somrak]

@johnrellis 

I still think there is a problem that could be solved here.

As you said the camera to os transfer is apparently not recording the milliseconds in the OS but the catalog has the Original Capture Time Stored IF it was changed in LrC, otherwise it is NULL.  The algorithm for changing the Capture time to Original for a group of photos should read the saved originalCaptureTime from the Adobe_Images table if it has a Time or skip if it is NULL.

Lightroom shows this on a newly imported image from R6mk2

This is what is recorded in the "Adobe_Images" table

 

Change the date to 2024

 

it is Changed in LC

 Change back to Original.  LrC is NOT reading the "originalCaptureTime" from the catalog but from somewhere else, probably OS.

 

 

 

 

 

 

[Bob Somrak]

I guess LrC has to read the original capture time from the OS file in case you wrote the corrected time to the file using Save Metadata.  

In addition, when you save the corrected time to the file it strips the milliseconds in the file.

Saved metadata to file and reimported file in my reply above

 

[johnrellis]

@Bob Somrak, I'm not seeing the fractional seconds get truncated.  Here are the steps I took:

1. Select a raw with capture time with fractional seconds but file-created time having no fractional seconds.

2. Do Edit Capture Time to change the year.

3. Optionally, do Save Metadata To File, with or without Catalog Settings > Metata > Write Date Or Time Changes Into Proprietary Raw Files.

4. Do Metadata > Revert Capture Time To Original.

Are you doing different steps?  

[Bob Somrak]

@johnrellis 

Sorry John.  I was in a rush at the time and forgot to put the steps in my last reply

1. Select a raw with capture time with fractional seconds but file-created time having no fractional seconds.

2. Do Edit Capture Time to change the year from 2023 to 2024

3. Optionally, do Save Metadata To File, WITH Catalog Settings > Metata > Write Date Or Time Changes Into Proprietary Raw Files.

4. Remove file from LrC

5. Reimport file to LrC

6. Do Metadata > Revert Capture Time To Original.

This is where the "original time" no longer has milliseconds.  

 

[jime40615875]

Hi everyone,

I’m hoping someone else can confirm what I’m seeing, or offer an alternative explanation. I’ve been doing a significant amount of catalog cleanup recently and seem to have uncovered a possible timestamp issue in the current version of Lightroom Classic.

Version Information

• Lightroom Classic 15.0.1 Release

• Camera Raw 18.0

• Build [202511041508-dddee541]
  (macOS Sequoia 15.6.1)

---

What I’m seeing

For a subset of photos (not all), Lightroom now shows a one-hour difference between:

• Capture Time in the Metadata panel
  vs.

• Original Time displayed in the Edit Capture Time dialog

This happens consistently by exactly 1 hour, and only on certain files.

---

Why this looks like a bug

To verify, I checked the actual EXIF of affected photos in macOS Preview. For example, one iPhone HEIC file shows:

EXIF (Preview > Inspector):
Date Time Original: 9/14/2023 08:57:23

Lightroom:

• Capture Time: 08:57:23.443 (correct)

• Original Time (Edit Capture Time dialog): 07:57:23.443 (incorrect by –1:00:00)

So Lightroom’s Capture Time matches the true EXIF value, but Lightroom’s “Original Time” value does not. It appears Lightroom is showing a shifted version of the timestamp that does not exist in the actual file.

---

Why this is puzzling

• iPhone files contain correct, fully timezone-aware metadata.

• Nikon files in my catalog show the same issue.

• Other files from these devices do not show the problem.

• The discrepancy seems to appear mostly on images where I recently added GPS coordinates (either via Lightroom’s Map module or manually using Google Maps coordinates).

• Files without recent GPS edits appear normal.

This suggests Lightroom may be re-parsing timestamps whenever GPS data is added, and the new timestamp parsing logic (introduced near the time of the millisecond-precision update) might be applying an incorrect timezone shift.

---

Why this matters

I rely heavily on accurate capture times for sorting, searching, aligning images from multiple camera bodies, and maintaining a clean catalog timeline. This inconsistency makes it difficult to confidently edit or batch-adjust capture times.

---

Open to other explanations

I’m definitely open to the possibility that I’m misunderstanding how the new timestamp parsing is intended to work. But because the EXIF timestamps in the files themselves are correct—and because Lightroom shows a correct “Capture Time” while simultaneously showing an incorrect “Original Time”—this appears to be a regression worth surfacing.

---

What I’m hoping to learn

• Can anyone reproduce this behavior?

• Is this a known issue with the current Classic release?

• Is there documentation clarifying how Lightroom now interprets timestamps with GPS metadata?

• Should this be escalated as a formal bug?

I’m happy to provide sample files if needed.

Thanks in advance for any insight or confirmation.

Note: text generated via ChatGPT based on extensive "discussions".

[jime40615875]

Just to add an important clarification after further checking:

It turns out this issue is not limited only to images where I recently added GPS/location data. I initially thought the discrepancy was tied primarily to my recent GPS-tagging work, but after digging deeper:

Additional observations

• The one-hour mismatch between Capture Time and Original Time is appearing on images from multiple different cameras, including:

  • iPhone

  • Nikon Z-series

  • Older Nikon bodies

  • Panasonic bodies

  • OMD body

  • Processed JPG/HEIC files

• It’s also affecting multiple file types:

  • HEIC

  • JPG

  • RAW (NEF)

  • Edited exports

• Some affected files have had no recent metadata editing at all (no added GPS, no changes).

• Others with GPS added show the same issue.

• And many files from the same devices remain completely unaffected.

So the problem doesn’t appear to correlate strictly with GPS updates. Instead, it seems Lightroom is selectively interpreting certain files differently depending on which EXIF timestamp/offset fields they contain. The inconsistent nature of which files are affected (even within the same camera roll or folder) makes this look less like user workflow and more like a parsing issue introduced recently.

Happy to provide sample files that illustrate both cases — affected and unaffected — from the same devices if that would help with troubleshooting.

[Bob Somrak]

@jime40615875 

Yes, others are having this issue ..It is an acknowledged bug.  Read through the entire thread and you will see what is causing the issue..

[Joyful_strategist3620]

When assigning a date and time to a scanned photograph, Lightroom Classic adds one hour to the desired time.  Example: if I tell Lightroom the time is 1:00PM, it will record the time as 2:00PM.   

Screen captures of problem and of operating environment attached. 

[Josh-H - WNPT]

What happens if you manually try and correct the time? Menu: Metadata / Edit Capture Time.

[Joyful_strategist3620]

The screenshot shown is the result after manually correcting the time. 

[AxelMatt]

It seems that's the known issue desribed here: P: Edit Capture Time displays times one hour earli... - Adobe Product Community - 15581099

[Rikk Flohr: Photography]

Greetings all, 

A new update for the Adobe Photography products has been released.  The December release 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. 

[Bob Somrak]

@Rikk Flohr: Photography 

Unfortunately this has NOT been fixed in LrC 15.1

[chrisfreeman804]

This has also been happening to me since updating to version 15 (and not fixed in 15.0.1).  I also assumed it was something with Daylight Saving Time.  Thanks to those who poked around!  Still waiting for a fix!

And my fear is that all the times I have typed purposely incorrectly for the past month or so will show up wrong after the fix.  Because in the metadata panel it will show the right time, but when you open the window to change the capture time, that window always shows the purposely wrong time I typed in (an hour off).

[Bob Somrak]

@chrisfreeman804 

You could try updating to 15.1 that was just released BUT it is still not fixed for me on 15.1  even though it was announced the issue was supposed to be fixed

[johnrellis]

@Rikk Flohr: Photography, I too observe this hasn't been fixed in LR 15.1.

[Rikk Flohr: Photography]

@Bob Somrak & @johnrellis 

Engineering (and I) are no longer able to reproduce this. 
We've reopened the bug. 

@Bob Somrak, Engineering will reach out to you directly if they haven't already. 

[Rikk Flohr: Photography]

Reopening ticket as it is reported as not-fixed. 

[Bob Somrak]

@Rikk Flohr: Photography 

Thanks.

I sent the info to Engineering that they requested.

[ras.phd]

This did not work. I had already added a data set for May 30, 2025.

The metadata time says 8 AM. My final naming convention is date and time for all files.. The file names are 7 AM

So I did the 15.1 update, Went straight there and reset the Meta date time at 7 AM . When the file renamed it renamed it 6 AM. It is not fixed.

[ras.phd]

Workflow is essential and this is a royal pain in the butt says we're going to have to go back and redo all file times And naming.

It also screws heavily with photo frames that use time time to sort photos..