Lightroom: Still inconsistent capture date/time for photos and videos

  • 55
  • Problem
  • Updated 4 weeks ago
  • Acknowledged
  • (Edited)
Update 5/17/2018: Though LR 7.1 made improvements, LR 7.3.1 still has two closely related problems with a single underlying cause:

- With photos and videos missing metadata capture date/times (e.g. scans), there is still an inconsistency between the times shown under the thumbnails in grid view and in the Metadata panel and the hidden, internal times used for sorting in grid view.

- Changing IPTC Date Created in the Metadata panel, either by editing the field or using Metadata > Copy/Paste Metadata, similarly causes inconsistent values to be shown and sorting and searching to work inconsistently.  It also causes date metadata to be written back to the files that doesn't conform with the Metadata Working Group's standard.

The underlying cause is architectural: LR doesn't have a single internal catalog field representing "capture time".  Rather, it maintains capture time in several different fields, and the various parts of LR update those fields inconsistently.

See here for precise recipes to replicate these bugs:

https://feedback.photoshop.com/photoshop_family/topics/lightroom-still-inconsistent-capture-date-tim...

https://feedback.photoshop.com/photoshop_family/topics/lightroom-still-inconsistent-capture-date-tim...

See here for a workaround: 

https://feedback.photoshop.com/photoshop_family/topics/lightroom-still-inconsistent-capture-date-time-for-videos?topic-reply-list%5Bsettings%5D%5Bfilter_by%5D=all&topic-reply-list%5Bsettings%5D%5Breply_id%5D=15475521#reply_15475521.  

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

LR 5.7 still shows inconsistent capture date/times for videos. For a test .avi on Windows 8.1, the date in grid view appears to be the file system's last-modified time, while Capture Date/Time is set to the time of import.This problem was declared fixed in LR 5.5, and it appears to have been fixed for images, but not videos:http://feedback.photoshop.com/photoshop_family/topics/inconsistent_dates_for_files_missing_date_time...I'm opening a new topic, since the previous one has been marked "Solved".
Photo of John R. Ellis

John R. Ellis, Champion

  • 4372 Posts
  • 1160 Reply Likes

Posted 5 years ago

  • 55
Photo of John R. Ellis

John R. Ellis, Champion

  • 4372 Posts
  • 1160 Reply Likes
The core issue is that LR doesn't have a single internal field that it uses consistently for capture time. This results in inconsistencies in a number of different places in the application: sorting, filtering, metadata display, renaming. But they all have the same root cause, the failure of the implementation to have an abstraction that provides a consistent value for "capture time".

The inconsistencies occur more often with video than with images, most likely because Adobe admitted in this forum that they never finished video metadata due to other priorities.

Gathering all of these inconsistencies in a single topic will make it more likely that Adobe will notice and address the core issue rather than apply incomplete baind-aids (as did once before).
Photo of Stephen Leggett

Stephen Leggett

  • 73 Posts
  • 5 Reply Likes
Would be useful of have a bullited list at the top, cataloging each identified instance of an error; would make it easier to identify whether Adobe has actually 'fixed' things
(Edited)
Photo of John R. Ellis

John R. Ellis, Champion

  • 4372 Posts
  • 1160 Reply Likes
I confirmed that for .mov (QuickTime) files produced by iOS 9, the Library > Rename Photo command is showing a similar inconsistency as the other use cases in this topic. In particular, the rename command is using the file system's modification date as "capture time", whereas the Metadata panel and the thumbnail use the QuickTime metadata field "Create Date" as the "capture time".

As an example, I used this renaming template:



to rename a .mov file. The new filename 2016-01-16--22-20-31.MOV corresponds to the file system's modification date. Whereas the date under the thumbnail and in the Metadata panel corresponds to the QuickTime metadata field Create Date:





The capture time shown under the thumbnail and in the Metadata panel is 8 hours after the local time at which the video was taken. (My computer is running in UTC-8.) This shift is due to a different bug in which LR trips over QuickTime's lack of time zones in some date/time metadata fields: http://feedback.photoshop.com/photosh....
Photo of tale

tale

  • 11 Posts
  • 3 Reply Likes
Had the same issue recently. As a workaround, reassigning the same date by using the method described by John in this topic worked for me ( http://feedback.photoshop.com/photosh... ).

Still... a proper fix would be much better :/
Photo of Daniel Arbeeny

Daniel Arbeeny

  • 46 Posts
  • 0 Reply Likes
Hi John,
How can I (or others) help gather info into one spot?
I always appreciate your help & insight!
Photo of Stephen Leggett

Stephen Leggett

  • 73 Posts
  • 5 Reply Likes
This reply was created from a merged topic originally titled New variant of Capture time bug.

I know this has been a long running issue, but the latest release has changed the behaviour of Capture Date and Time for the worse

Sequence of events:
1. Import scanned image without any metadata in the Capture Date/Time Fields
2. Copy Metadata from existing image including those fields
3. Paste into the newly imported image
4. Select a folder containing the image, sorted by capture time

Previous version (numbers refer to above steps):
1. Capture date/time not shown in right column
3. Capture date time shown as pasted values
4. Image appears according to displayed date/time

Current version:
1. Capture date/time not shown in right column
3. Capture date time shown as pasted values
4. Image appears according to create/import time (I can't determine which) rather than displayed values

Now this can be fixed on the image by opening the Metadata edit capture time dialog and selecting change.

This places image in the correct place in the sequence but is yet another pointless step I have to add to my workflow.
Photo of John R. Ellis

John R. Ellis, Champion

  • 4260 Posts
  • 1132 Reply Likes
It's not clear to me yet that CC 2015.6 behaves differently than previous versions with respect to scans missing capture times:

1. Please do Help > System Info and report the exact version you're running.  Many think they are running "the current version" but in fact aren't due to problems with the Creative Cloud desktop app.

2. "Copy Metadata from existing image including those fields".  Exactly how are you copying the metadata?  With the menu command Metadata > Copy Metadata?  Which fields are you selecting to be copied?  (There is no field available in that window that corresponds to what LR displays as capture time.)

3. "Image appears according to create/import time (I can't determine which) rather than displayed values".  LR has long been inconsistent in how it sorts images missing capture time in their metadata.  

LR's handling of missing capture time is a complete mess. To determine if your situation is in fact different in the CC 2015.6, it would help to have two sample photos in hand, the scanned photo missing the capture time and the photo from which you are copying metadata values.   You could upload them to Dropbox (or similar) and copy the sharing link here.
Photo of Stephen Leggett

Stephen Leggett

  • 73 Posts
  • 5 Reply Likes
Well its absolutely clear to me that it changed in the recent release, and the behaviour changed for the worse - see below

Only the images I have imported and copied metadata to since that release have this problem. These images are NEF raw files, with XMP sidecars that are generated by LR; files from which I am copying the data are in general Tiffs.

1. I'm running the latest version Lightroom 2015.6 release Camera Raw 9.6, CC reports no updates available. Running on OSX 10.11.5 - App Store update reports no updates available

2. Copy Metadata from menu, Paste Metadata from menu. Check Filled; IPTC Image - Date Created - this is the field that is changed on the display of Capture time in the right panel, is populated on the source and is pasted into at least one place.

So when the image is initially imported, the field does not appear in the right panel, when I copy the metadata the field appears and is populated with the date and time from the other image. This behaviour is as in earlier versions.

However, the paste behaviour has changed such that some other field is no longer populated - which one this is ??? This appears to be used in sorting collections/folders in capture time sequence as the sequence is wrong for images I imported since updating to the LR 2015.6 release.

As I previously said, selecting the images and Men-> Edit Capture time; Change - fixes the problem, so this activity is populating the field that Paste Metadata no longer touches.

What Edit Capture time change appears to do, and I can't guarantee it as its only a visual check, is write extra lines to the sidecar, with a value for  exif:DateTimeOriginal set to the date that I pasted. However, and more garbage, it also appears to write a line labelled xml:ModifyDate with exactly the same value as DateTimeOriginal. So it appears to me that the behaviour was changed to omit writing one or more of these on the Paste.

3. What I meant there is that its not my job to QA and frankly I couldn't be bothered to work out which it was sorting on - as you said its a mess and has been for 5 years+
Photo of Stephen Leggett

Stephen Leggett

  • 73 Posts
  • 5 Reply Likes
This is not a bug about sorting the display, this is a recently introduced bug in Paste metadata (from the menu) that makes the issues with display worse.
Photo of Stephen Leggett

Stephen Leggett

  • 73 Posts
  • 5 Reply Likes
And heres another related item, don't whether this is new/old but still inconsistent behaviour, same versions as before (2015.6 etc)

1. Import image without date/time data
2. Metadata; Edit Capture Time; Change (with no change to data)
3. Copy/Paste Date Created etc from another image via Menu items

Displayed date in right panel for the target image doesn't change in the way it does if you did not do step 2; it remains as displayed before action 3

Edit: removed reference to step 1 in last paragraph
(Edited)
Photo of Stephen Leggett

Stephen Leggett

  • 73 Posts
  • 5 Reply Likes
Issue with imported, then pasted metadata sorting in wrong order (i.e. the bug in described in the reply to which this is a comment) is not fixed in LR 2015.6.1 running on OSX 10.11.6
Photo of John R. Ellis

John R. Ellis, Champion

  • 4372 Posts
  • 1160 Reply Likes
This reply was created from a merged topic originally titled Lightroom: Editing IPTC:Date Created produces incorrect, inconsistent results.

Editing Date Created in the Metadata:IPTC panel does not completely set LR's notion of capture time, nor does it properly set EXIF:DateTimeOriginal, as specified in the industry standard that Adobe has sponsored. The results vary inconsistently depending on whether the imported file already contains IPTC:DateCreated.

To reproduce:

1. To reproduce in LR 5.2 (Windows 7 64-bit):

2. Import a photo with no EXIF, XMP, or IPTC fields.

3. In the Metadata:IPTC panel, change Date Created to 2009-04-13.

4. Note that the Metadata:Default panel shows that date as Capture Date, and that date will show under the thumbnail in Library grid view. But the image will not sort properly by capture time in Library grid view, and the smart-collection criterion "Capture Date is 2009-04-13" does not properly match the image.

5. Do Metadata > Save Metadata To File.

6. Remove the file from the catalog.

7. Examine the file's metadata with Exiftool and observe that IPTC:DateCreated and XMP:DateCreated have been set, but EXIF:DateTimeOriginal has not, even though "Guidelines for Handling Image Metadata Version 2.0" specify on page 38 that "Changes to XMP ... SHOULD be exported to Exif. ... This is also true in the case that only IPTC DateCreated is available."

8. Use Exiftool to remove XMP:DateCreated from the image, so that it now has just IPTC:DateCreated.

9. Reimport the image.

10. Note that the date is shown in the Metadata:Default panel as Capture Date and under the thumbnail in Library grid view. The image sorts properly by capture time in grid view. The smart-collection criterion "Capture Date is 2009-04-13" properly matches the image.

11. In the Metadata:IPTC panel, change Date Created to 2009-04-09.

12. Note that the Metadata:Default panel now shows Capture Date as 2009-04-09, as does the date under the Library thumbnail. But the thumbnail does not sort properly in Library view, and the smart-collection criterion "Capture Date is 2009-04-09" does not match the image.
Photo of John R. Ellis

John R. Ellis, Champion

  • 4372 Posts
  • 1160 Reply Likes
This problem was reported in LR 5.2.  I just retested, and it still occurs in LR CC 2015.6.  The same underlying cause: Internally, LR doesn't have a uniform abstract concept of "capture time", and different parts of LR use different metadata fields in different ways.  
Photo of Stephen Leggett

Stephen Leggett

  • 73 Posts
  • 5 Reply Likes
There is a much simpler route to showing there is a bug in LR

1. Choose a catalog with Automatically write changes into XMP set on
2. Close Lightroom
3. Create a raw image without an exif date (in my case .NEF file from Nikon Coolscan (referred to as ImageA below)
4. Using the OS, copy the file (referred to as ImageB)

So, you now have two identical files.

5. Start LR
6. Import both files in a single operation
7. On ImageA, Menu - Metadata; Edit Capture Time; Confirm (without changing anything)
8. Choose a completely different image (ImageC) with no known problems and which has a properly populated IPTC Image; Date Created field
9.  Select ImageC; Menu Copy Metadata (ensuring the field is checked)
10. Select ImageA; Menu Paste Metadata
11. Select ImageB; menu Paste Metadata

So, same metadata should be on each image? Sadly no.

On the default Metadata panel on the right:
ImageA shows - Original create date (i.e. date the file was created by scanner)
ImageB shows - Date from ImageC

No magic; no editing of files; just LR getting it wrong.
Photo of John R. Ellis

John R. Ellis, Champion

  • 4372 Posts
  • 1160 Reply Likes

Changing IPTC Date Created, either through the Metadata panel or (as you discovered) by pasting from another photo, has long caused inconsistencies in LR's notion of capture time, at least for photos that originally had no capture-time fields.  I just merged in this bug report on the problem from LR 5.2: https://feedback.photoshop.com/photoshop_family/topics/lightroom-still-inconsistent-capture-date-time-for-videos?topic-reply-list%5Bsettings%5D%5Bfilter_by%5D=all&topic-reply-list%5Bsettings%5D%5Breply_id%5D=17007648#reply_17007648.   These inconsistencies can affect the dates shown under thumbnails, the dates shown in the Metadata panel, the dates used for sorting, and the dates used for renaming files.

Architecturally, LR lacks a single internal notion of "capture time" that is used uniformly throughout the app.  Rather LR uses a hodge-podge of inconsistent rules for interpreting the multiple industry-standard metadata fields that represent capture time.  The Metadata Working Group spec provides clear rules for doing this, but LR doesn't implement the rules correctly.  Adobe was a member of the MWG, and LR 3.4 was supposedly changed to follow the MWG spec: http://blogs.adobe.com/lightroomjournal/2011/04/lightroom-3-4-and-camera-raw-6-4-now-available.html. But it's become evident over the years that was botched.

In my opinion, Adobe has never made fixing this a priority because most of the inconsistencies arise from photos and vidoes that don't have capture dates (or, in the case of videos, don’t' have capture dates that LR knows how to read). Whereas LR was originally targeted towards handling photos from digital cameras, and nearly every digital camera writes EXIF:DateTimeOriginal to its files.  And LR knows how to read the capture time of the video formats used by most of the prosumer cameras, and they all put capture time in the standard QuickTime / MP4 location.

It's never been a priority for LR to support people using LR as a general-purpose digital asset manager, e.g. for cataloging scans.  And though LR claims to support video, support for video metadata has always been incomplete (years ago, one developer acknowledged that was an issue of priorities).


Photo of Stephen Leggett

Stephen Leggett

  • 73 Posts
  • 5 Reply Likes
Well,  maybe some Adobe staff member would confirm that they actually looked at this page.

Above, I gave an example that takes less than three minutes to execute, involves no third party software and clearly demonstrates patently obvious bug

Sixth major release, yet 'copy and paste' doesn't work !!

When they have looked at it, maybe they would have the grace to respond:
a) Can't reproduce - in which case I'll put a screen capture together, or
b) Yes it is a bug and we will fix it by..., or
c) Yes its a bug and we will never fix it
Photo of Stephen Leggett

Stephen Leggett

  • 73 Posts
  • 5 Reply Likes
Thats as maybe, but last time I looked this was 2016.

Copy and paste as a computer concept originated sometime in the 1960's, so approximately 50 years ago.

Long enough I would have thought to master the idea.
Photo of Stephen Leggett

Stephen Leggett

  • 73 Posts
  • 5 Reply Likes
Well, I  didn't really expect a response, however much fun it was writing the comments :))
Photo of Daniel Arbeeny

Daniel Arbeeny

  • 46 Posts
  • 0 Reply Likes
I have an idea. I wonder if we could import video into PSE and which should capture the right info and them import that into LR.
Photo of Stephen Leggett

Stephen Leggett

  • 73 Posts
  • 5 Reply Likes
A. Architecture comments
“Architecturally, LR lacks a single internal notion of "capture time" that is used uniformly throughout the app”

It seems to me that there is now a "single internal motion"; I can't speak for earlier versions.

Its the "used uniformly" that continues to be the issue.

This is the schema for the table in the catalog for the Image:

TABLE Adobe_images (
    id_local INTEGER PRIMARY KEY,
    id_global UNIQUE NOT NULL,
    aspectRatioCache NOT NULL DEFAULT -1,
    bitDepth NOT NULL DEFAULT 0,
    captureTime,
    colorChannels NOT NULL DEFAULT 0,
    colorLabels NOT NULL DEFAULT '',
    colorMode NOT NULL DEFAULT -1,
    copyCreationTime NOT NULL DEFAULT -63113817600,
    copyName,
    copyReason,
    developSettingsIDCache,
    fileFormat NOT NULL DEFAULT 'unset',
    fileHeight,
    fileWidth,
    hasMissingSidecars INTEGER,
    masterImage INTEGER,
    orientation,
    originalCaptureTime,
    originalRootEntity INTEGER,
    panningDistanceH,
    panningDistanceV,
    pick NOT NULL DEFAULT 0,
    positionInFolder NOT NULL DEFAULT 'z',
    propertiesCache,
    pyramidIDCache,
    rating,
    rootFile INTEGER NOT NULL DEFAULT 0,
    sidecarStatus,
    touchCount NOT NULL DEFAULT 0,
    touchTime NOT NULL DEFAULT 0
);

Clearly has a column central to the image - captureTime and I only see one row in the table per image in the catalog.

Now, there are other date and time fields scattered about, such as originalCaptureTime in the same table and dateDay, dateMonth, and dateYear in AgHarvestedExifMetadata

So there are at least three classes of problem:
1. Not setting captureTime correctly in table Adobe_images
2. Not using captureTime when it should be used
3. Inconsistent use when captureTime is not set.

Correcting any problem in one of these classes doesn’t fix anything in that or the other classes, which to me, and I see others, emphasises why each problem should have its own thread.

B. Problem reporting best practice.

“Gathering all of these inconsistencies in a single topic will make it more likely that Adobe will notice and address the core issue rather than apply incomplete band-aids”

This seems to be a common idea across this site as I see it in several other problem threads.

Having managed a global IT support desk, I say this is misguided.

Best practice for problem/incident reporting includes the following:
1. A unique reference for each problem report
2. A single problem per report
3. Feedback from those reporting the problem on how the issue was managed (taking a sample is acceptable here)

Having experienced both processes in the past few months, I find it ironic that Western Digital, a (primarily) hardware supplier can achieve these for problems in the software it produces but Adobe can’t.
Photo of Stephen Leggett

Stephen Leggett

  • 73 Posts
  • 5 Reply Likes
Here is what appears to the the root of the problems for non-video images. I suspect the same is true for video as well but haven't tried that.

There is an additional text string field ‘xmp’ on table ’AdobeAdditionalMetadata’

Often, but not always, this holds the value of capture time as ‘exif:DateTimeOriginal’.

It seems that the code prefers to use the value in the xmp field, largely ignoring captureTime on Adobe_images and AgHarvestedExifMetadata.

So what appears to happen on import of an images with ‘missing’ metadata is that the Import function:

  • Populates captureTime on Adobe_images
  • Populates AgHarvestedExifMetadata, fields dateDay, dateMonth and dateYear with corresponding values
  • Does not write exif:DateTimeOriginal into the xmp field on AdobeAdditionalMetadata

Now the effect of this varies according to the relevant piece of code. For example, what seems to happen if exif:DateTimeOriginal is absent:

  • Metadata panel to right of screen - shows nothing, not even the field labels
  • Date shown under image in grid view uses captureTime on Adobe_images
  • and so on

When you select an image, then Menu -> Metadata- >Edit Capture time and confirm, the result is that a line is written to the xmp field exif:DateTimeOriginal and (some) things start working again.

Hackers solution:

  • change the import function to write exif:DateTimeOriginal to the xmp field

Professional solution:

  • change the relevant code to use captureTime on Adobe_images

Adobe solution

  • Hmmm...
Photo of Stephen Leggett

Stephen Leggett

  • 73 Posts
  • 5 Reply Likes
For the sake of clarity, I should have said there is a value in the xmp column on AdobeAdditionalMetadata even if no xmp sidecar file has been written for that image.
Photo of Stephen Leggett

Stephen Leggett

  • 73 Posts
  • 5 Reply Likes
More on non-video images.  I haven’t tried this on video but suspect its similar.

This time Copy and Paste date metadata.

Again, this refers to what is held in the catalog not; NOT any external xmp files that are created.

  1. So select an image with ‘good’ data; that is one from a camera supported by Lightroom
  2. Menu -> Copy Metadata -> Check filled > Copy (ensuring the ‘Date Created’ field has a value and is checked)
  3. Now select any image; whether its got exif data or not
  4. Menu -> Paste Metadata

What a mess you end up with...

The Paste:

  • Doesn’t create exif:DateTimeOriginal in the xmp column on AdobeAdditionalMetadata should that field not exist
  • Doesn’t update exif:DateTimeOriginal in the xmp column on AdobeAdditionalMetadata if it does exist
  • Doesn’t ever update captureTime on Adobe_images
  • Doesn’t ever update AgHarvestedExifMetadata, columns dateDay, dateMonth and dateYear
  • Does create/update photoshop:DateCreated in the xmp column on AdobeAdditionalMetadata

Consequently, there are now several different sets of capture time on the image.

No wonder there are inconsistencies.

Now, it appears that some of the code, such as display of Capture Time on the rightmost Metadata panel, uses:

  • exif:DateTimeOriginal if present in the xmp column on AdobeAdditionalMetadata,
  • failing that will use photoshop:DateCreated from the same source
  • failing that won't display anything
Result:
  • If exif:DateTimeOriginal existed for the image, its not updated and so it appears that the paste hasn’t worked as the new value gets placed in photoshop:DateCreated which is not used as its not the preferred field;
  • If exif:DateTimeOriginal did not exist the new value gets placed in photoshop:DateCreated and it appears that the paste worked (in some places at least)

Hacker solution:

  • If a copied field, have paste write/update exif:DateTimeOriginal in the xmp column on AdobeAdditionalMetadata

Professional solution:

1. If a copied field, have Paste update/write
  • captureTime on Adobe_images
  • AgHarvestedExifMetadata, columns dateDay, dateMonth and dateYear
  • exif:DateTimeOriginal in the xmp column on AdobeAdditionalMetadata
2. Provide a utility to bring the database fields back into sync.

Adobe solution:

  • Hmmmm...
Photo of Alan Harper

Alan Harper

  • 453 Posts
  • 92 Reply Likes
This reply was created from a merged topic originally titled Filter bar by date.

I can't tell if this is a new bug, or just a feature/bug/annoyance that I somehow overlooked.(Lightroom CC 2015.6)

I put an image that I downloaded today into Lightroom, and then set its Date Created to the correct date (Oct 21, 2007). However, if I try to use the Filter Bar to find it, it shows up as today's date, not the date taken. I would like to be able to use the Filter Bar to find other photos taken the same day.

Exiftool has this to report on the file:
File Modification Date/Time     : 2016:08:20 14:01:37-07:00
File Access Date/Time           : 2016:08:20 14:01:54-07:00
File Inode Change Date/Time     : 2016:08:20 14:01:37-07:00
Metadata Date                   : 2016:08:20 14:01:37-07:00
Date Created                    : 2007:10:21

The metadata panel for the image says:


But if I put it in a folder and then use the Filter Bar I see:
Photo of John R. Ellis

John R. Ellis, Champion

  • 4340 Posts
  • 1154 Reply Likes
See this previous post in this same topic: https://feedback.photoshop.com/photoshop_family/topics/lightroom-still-inconsistent-capture-date-tim... . 

The annoying but easy workaround is to always use Metadata > Edit Capture Time, rather than change the Date Created field.
Photo of Alan Harper

Alan Harper

  • 453 Posts
  • 92 Reply Likes
Since this got merged, it appears that my proposed solution to my problem did not get merged as well. I find that if I Save Metadata and then Read Metadata, all the inconsistencies go away. This is easier to do than other proposed solutions in this thread.

I suspect it works because Lightroom has code to map its internal state onto the metadata, and then on reading the metadata, the internal fields become consistent. (Of course, the various Date metadata fields may not be what you want--but that is a different problem).

Stephen Leggett reported that this solution did not solve his problems, so YMMV. And, of course, this doesn't help with videos, the original subject of this thread, since you can't write metadata for videos in Lightroom.
Photo of Stephen Leggett

Stephen Leggett

  • 73 Posts
  • 5 Reply Likes
And as I pointed out in previous thread that you trashed, the Edit Capture time and Save meta data sticking plasters don't fix the problem that Paste creates because the date it writes is invisible to both these operations

Still, given this is now successfully hidden on five year old thread, expectations of Adobe fixing this..... 
Photo of John R. Ellis

John R. Ellis, Champion

  • 4340 Posts
  • 1154 Reply Likes
Adobe uses this forum to help gauge how many people are affected by a bug.  The more people who me-too and follow a topic, especially with meaningful details, the more likely Adobe will prioritize a solution.   This topic has 23 me-toos; but if the topic were split out into the individual bug reports of the different symptoms of the underlying defect, no single bug report would likely have more than half a dozen me-toos.  

The date of the original post is immaterial -- what matters are the dates of the recent posts and the number of me-toos.  Recent posts ensure the topic is bumped to the top of the feed and will make the posts just as likely to be read as starting a new topic.

Annoyingly, the forum software only displays the first post of a merged topic. However, you can still reach the follow-ups by clicking on "This reply was created from a merged topic originally titled Filter bar by date."   You can also repost replies in the merged topic, if warranted (which I occasionally do).
Photo of Stephen Leggett

Stephen Leggett

  • 73 Posts
  • 5 Reply Likes
So which of the dozen or so bugs in this thread have I said I have too?

If Adobe ever admit to/replicate/fix one of them (LOL) how does it set the status of the thread - e.g. if it says 'In Progress' (LOL even louder) does that mean they are all in progress or do I have to hope its the one I'm interested in, does 'Solved' mean all of them and so on...

As I said above, for any professional error reporting system, its one bug one report; only way you can unambiguously monitor whats going on.

Key word there was professional.
Photo of Jim Barton

Jim Barton

  • 9 Posts
  • 0 Reply Likes
I am frustrated having installed Lightroom in September 2016.  It has randomly messed up file "Capture Time" which is what LR uses to sort by.
In a run of photos taken by the same camera, it suddenly decided to use the date of installation of Lightroom .

It shows a capture time of 12/09/2016 16:25:10 
EXIF only has Digitized of  08/02/2005 12:29:33  - THIS IS THE ACTUAL TIME AND DATE THE PHOTO WAS TAKEN
Yet if I ask LR to change the Capture TIme to the Original File Creation Date, that is shown as 14/05/2005 23:07:46, which is ABSOLUTELY NOT correct.

So using the Lightroom File Creation Date would cause yet more problems.

The ONLY good thing about this is that I used a previous program (that sadly no longer works in Windows 10) to add the file creation date to the front of the file name.  So I can be sure that is right.

The IPTC File Creation Date is correct at 2005-02-08T12:29:33+0000

Lightroom is causing me a lot of problems, and this is just one that is totally unnecessary.

This forum / community help section is most strange. It seems to have no formatting options and no file insert options yet many people are managing to post screen shots.  Ah - a Firefox problem.

HANG ON JUST A SECOND>...

If I get LR to show "Default" metadata, the information presented shows me that the file "Capture Time" is entirely different from the file "Capture Time" shown in the information on the thumbnail.


Lightroom sorts by the Capture Time as shown on the thumbnail, not as shown in the default metadata.

In fact, the field that LR changes is "Date/Time Original" in the EXIF data.  SO it is calling a known field by a different name, and not using the actual IPTC field called Capture Time.  AAARRRGGGHHH.

So basically it is a mess.

The file before that has its Capture Time OK, exactly the same as its other Date/Time fields.


What I need to be able to do FOR MANY PHOTOS is change the so-called Capture Time to the correct "Digitised Time", but there seems to be no easy way of doing so.  CAN IT BE DONE?

Lightroom forces me to do each one manually, because if I bulk change them to a manually set time, they all get much the same time of day allocated, as Lightroom imported them all within a minute.
(Edited)
Photo of Bruce Lull

Bruce Lull

  • 3 Posts
  • 0 Reply Likes
The bug is particularily annoying to me as Photoshop Elements hands dates more effectively so it proves that somewhere in Adobe they understand the problem but don't bother to do anything about it.

I have ended up using Elements where I need correct dates (reporting and sorting) and Lightroom where I am working with date insensitive photos or collections where I can use folders to help me locate things effectively.

Photos taken digitally seem to be more likely to be handled correctly in Lightroom, but heaven help those who want to date scans or photos with corrupt dates from earlier processing,

This is (as commented recently by others) not being handled professionally. 
Photo of Keith Ely

Keith Ely

  • 7 Posts
  • 0 Reply Likes
JAN 2017 Brand new subsciption LR on new Imac:  Have 100 Nikon Coolscanned tif slides in LR.  I just learned how to individually or group edit Metadata Capture time Date.  I change the month and year to match the indiv. slide I scanned a few days ago.  Bug: the year says 2017, I highlight it and try to type 1993 and it accepts 199 and then when I type the 3, the field changes to just 3 and looses almost 2000 years.  This happens on many photos, not all.  Sometimes a backspace or few will allow 3 digit year, sometimes nothing will allow a 4 digit year like 1993.  Jeez.  I will shut LR down all the way and restart Imac next.   Edit an hr. later: Just did that,  no better, tried entering year field before month field, that worked for 20 slides, now that doesn't work. Still can't enter 1993 or 2001 as capture year reliably. Jeez.
(Edited)
Photo of Keith Ely

Keith Ely

  • 7 Posts
  • 0 Reply Likes
Here's my Lightroom Help Info: Lightroom version:  CC 2015 [1014445]License: Creative Cloud
Operating system: Mac OS 10
Version: 10.12 [2]
Application architecture: x64 .     What does this mean??
Photo of John R. Ellis

John R. Ellis, Champion

  • 4342 Posts
  • 1154 Reply Likes
You're running an old version (CC 2015.0).   Update to 2015.8 by doing Help > Updates.  If you have trouble with that, see here: http://blogs.adobe.com/lightroomjournal/2013/06/keeping-lightroom-up-to-date.html
Photo of Keith Ely

Keith Ely

  • 7 Posts
  • 0 Reply Likes
Now have 2015.8 . Still have LR CC trouble AND just tried to adjust Apple Photo Metadata for the jpgs in Photos and guess what, my new Imac basically can't accept 4 digit year for updated metadata year, done under Photo, Image, Adjust date and time, all I photo seems to allow is bumping the year up or down with the arrows next to the time and date window, so its alot of bumps to go from 2017 to 1960 on each slide, OUCH.
Photo of John R. Ellis

John R. Ellis, Champion

  • 4342 Posts
  • 1154 Reply Likes
Just to triple-check: Do Help > System Info -- does that show 2015.8?  (The CC update mechanism not infrequently fools people into thinking they've got the latest.)
Photo of Keith Ely

Keith Ely

  • 7 Posts
  • 0 Reply Likes
Lightroom version: CC 2015.8 [ 1099473 ]License: Creative Cloud
Operating system: Mac OS 10
Version: 10.12 [2]

My Imac program: Iphoto also can't accept a typed 4 digit year when I try, it only reliably accepts bumps of 1 year at a time, or hold down to spin year at medium speed.
Photo of Alan Harper

Alan Harper

  • 453 Posts
  • 92 Reply Likes
HI Keith. Just to be clear, you are trying to edit the date using the menu command "Metadata:Edit Capture Time..." and then you have selected "Adjust to a specified date and time". Correct?

This may be a wild guess, but what are your settings for Date/Time on your Macintosh (in System Preferences app)? This is what mine look like and I cannot replicate your bug.

Photo of Keith Ely

Keith Ely

  • 7 Posts
  • 0 Reply Likes
Solution: AH, my Imac Photos has the same difficulty entering 4 digit year, so I got good Apple phone help:    Because I hunt and peck numbers above the letters on my Imac keypad I am slow.  Apple Sr Advisor for Photos suggested I type the year, say 1987 more quickly.  This has worked on 5 photos in Apple Photos.  The advisor thinks as the Photos program matures into its 2nd, third and later years, it will be able to tolerate slow typists more and more.  There is aways a paste option for when I'm really old.  I can't wait to see if LR likes fast typists just as much.  Thank to those on this site for their help 24/7
(Edited)
Photo of Alan Harper

Alan Harper

  • 453 Posts
  • 92 Reply Likes
Yes, if you pause when you are typing the digits, Lightroom resets the number. I wonder if there is a setting for people who have motor control problems.
Photo of Keith Ely

Keith Ely

  • 7 Posts
  • 0 Reply Likes
Ahhhhh .  LightroomCC Library, like Imac "Photos" lets me change the Metadata's four digit year when I type the numbers quickly.  If you hunt and peck the numbers slowly you get really bad results in both programs.
Photo of Victoria Bampton - Lightroom Queen

Victoria Bampton - Lightroom Queen, Champion

  • 4914 Posts
  • 1913 Reply Likes
Check you're actually running the latest version (2015.8) as this sounds a lot like a bug that was fixed months ago.
Photo of Mikkel Saatvedt Dahr

Mikkel Saatvedt Dahr

  • 2 Posts
  • 1 Reply Like
Im not sure if my particular instance of this issue is already addressed earlier in this thread, but I will ad it anyways to be sure that it is represented.
I am running 2015.8 version of LR, on a OSX Sierra 10.12.3 
In the metadata panel, the option to chose date - "unknown" is not available, as you see below. Apparently Lightroom does not think that these images are without date. Lightroom seems to have a opinion about the date and time of these images, that it suggests when I go into "edit capture time..." with one of these images selected. But as you can see in the image bellow, the chosen image has no capture date and time information in the metadata panel to the right.


Thanks a lot to: johnrellis for answering my post about this, and directing me here.
Hope Adobe fixes this!
(Edited)
Photo of Jim Barton

Jim Barton

  • 9 Posts
  • 0 Reply Likes
This reply was created from a merged topic originally titled Inconsistent capture dates.

Thank you to  John R. Ellis, Champion - I have been able to begin to fix the incorrect dates allocated by Lightroom.  But I am still of the opinion that Lightroom is not importing the information correctly when it is in the EXIF.

I found this thread because I am really frustrated with Lightroom, and could not find out how to fix the mess it seemed to have made of my jpgs.  These were taken with my own digital cameras.

I installed Lightroom as part of the CC Photography suite on 14 October 2016.   It has set a huge number of them to a "Capture Date/Time" of then.  Initially I thought it was setting them to that date of import, but it seems that is because it used the last time the file was changed, and most files had their "ModifyDate" amended on that date.

Looking at exactly the same photos in Windows explorer and other programs shows their correct time under "Date/Time Digitised". 

Until today, all I could tell was that Lightroom was doing it "wrong".  It has internally allocated its "Capture Date/Time" field but doesn't show it except in sorting.

Following the suggestion of using attributes to filter, I find that most of my files show under "unknown" in the Date column.  So why does Lightroom show a date in the "Capture Date/Time" that it uses for sorting? How can it say unknown yet have a "Date/Time Capture"?  Why is it "Unknown" when there are valid entries in the EXIF? This inconsistency has caused me to waste so much time.

I have now looked at the EXIF using ExiftoolGUI.  There is a field called "DateTimeOriginal" which is I am guessing what you mean in your comment above by  "original date/time" field. That has the correct information, as does the field "CreateDate".  So it should work.  Lightroom has just ignored those, and used the date of last modification to set the "Capture Date/Time" which it insists on using as the default field for sorting!  If Lightroom would allow sorting by the other fields, it would not be as important.


Thanks to this thread, I have now found the way of using ExifTool and ExifToolGUI to fix the date and time so that the incorrect data is corrected and files are sorted correctly by Lightroom.

There is now a field called "Date Time Original" in the EXIF section of Metadata in Lightroom, that was not there before:


So what happened? 

It appears that prior to Lightroom importing the files, some XMP data has been lost, or not created. Because there is SOME XMP data, Lightroom then ignores valid EXIF data.

I fixed the first mentioned files before doing screenshots, so for comparison, here is the Metadata as shown in Lightroom for two other files.  The first has been given an erroneous Capture Date/Time; the second is correct.



In ExifToolGUI, the missing fields are XMP:CreateDate and XMP:ModifyDate.  All of the EXIF fields are there and correct.  Yet Lightroom only allocates the correct date for sorting to the file below which for some reason has those XMP fields.



The two files are on dropbox in case looking at them will help confirm whether I have worked out the issue, or if there is something else that Lightroom is doing / not doing.  Do I need to report a continuing bug?

https://dl.dropboxusercontent.com/u/31011761/Lightroom/20030615%20Canon%20PowerShot%20A40%20105_0585.JPG

https://dl.dropboxusercontent.com/u/31011761/Lightroom/20030615%20Canon%20PowerShot%20A40%20105_0592...

Note: This conversation was created from a reply on: Lightroom: Swaps "Date Time" and "Date Time Original" in Location.
Photo of John R. Ellis

John R. Ellis, Champion

  • 4279 Posts
  • 1138 Reply Likes
Jim, I imported the files you posted into my LR CC 2015.8, and LR imported the capture times from both correctly.  They both have valid EXIF:DateTimeOriginal fields/

585.JPG:
[EXIF]          Date/Time Original              : 2003:06:15 12:53:56


592.JPG:
[EXIF]          Date/Time Original              : 2003:06:15 14:48:00


I see from the metadata that both pics had their metadata changed by LR 6.6.1 on 2016:09:12.   Do you have a sample pic that still imports incorrectly?

As you can see from this thread, LR has a long-standing bug and behaves inconsistently when it imports a pic that is missing capture date recorded in the metadata fields EXIF:DateTimeOriginal or XMP:DateCreated (sic, XMP:CreateDate is when the pic was digitized, not when it was captured).  That is almost certainly what is happening to you.  But we can confirm if you post a pic that still imports incorrectly.
Photo of Arnold Bartel

Arnold Bartel

  • 196 Posts
  • 52 Reply Likes
I'm having a similar issue when sorting in collections including pictures and some sort of movies:

pictures typically have filled in different EXIF time information ensuring correct sorting:



(some) movies seem to have other EXIF time information. I don't know where the (correct!) timestamp above the picture comes from, but it is not listed in the EXIF panel onthe right and it is not considered for sorting:


This leads to the situation that in many times the pictures are listed first and the movies are listed in the end independent of their capture date.
Photo of John R. Ellis

John R. Ellis, Champion

  • 4361 Posts
  • 1160 Reply Likes
You've tripped over the bug described in this thread -- LR behaves inconsistently when it isn't able to read a capture date from a photo's or video's metadata.  See this post for a workaround: https://feedback.photoshop.com/photoshop_family/topics/lightroom-still-inconsistent-capture-date-tim...
Photo of Keith Ely

Keith Ely

  • 7 Posts
  • 0 Reply Likes
LIghtroom capture date entry appears to actually match Apple Photos.  I called Apple and was handed to an expert that said I need to type the year rapidly, not hunt and peck.  If a really old slow typing person were entering, they should "paste in" the entries so the typing is rapid.  With rapid typing of the year I've successfully entered a manual capture year correctly each time for 200+ 35mm slides.
Photo of Peter Gardner

Peter Gardner

  • 1 Post
  • 0 Reply Likes
This reply was created from a merged topic originally titled Changing Capture Time (doesn't update sort order).

I am trying to scan a large number of slides and import them into Lightroom. 
I need to change the capture time on all photos taken on a particular day from the scan date to the correct date. I tried doing this by:
Change Capture Time on one photo
Then with that photo selected in grid view: Library / Metadata / Copy Metadata then tick IPTC Image & Date Created
Then select all other photos taken on that day and: Metadata / Paste Metadata
This changed the Capture Time on all these photos, but Lightroom sorting in Grid View by Capture Time didn't use this new Capture Time, other than for the original photo changed, but still used the scan date.
If I go into Library / Metadata / Edit Capture Time and without changing the Capture Time click on the Change button the grid display sort by Capture Time picks up the correct Capture Time. This however would be very time consuming to do for thousands of slides.
Photo of Alan Harper

Alan Harper

  • 453 Posts
  • 92 Reply Likes
See my post https://feedback.photoshop.com/photoshop_family/topics/how-i-set-the-capture-time-of-a-bunch-of-phot... Let me know if it isn't clear or doesn't work for you.
Photo of John R. Ellis

John R. Ellis, Champion

  • 4342 Posts
  • 1154 Reply Likes
Editing IPTC Date Created or pasting it from another photo causes LR to get very confused about what it thinks the photo's capture time is.  See this post in this same topic for more details:

https://feedback.photoshop.com/photoshop_family/topics/lightroom-still-inconsistent-capture-date-tim...

This is one symptom among many of the same underlying cause, which is that LR maintains the capture time of a photo in several different fields in the LR catalog.   Different parts of LR don't keep all the fields updated correctly, and some parts read one field, and some another.  It's an architectural mess.

The problem is most often encountered with imported photos missing EXIF:DateTimeOriginal, e.g. scans, and as the result of editing IPTC Date Created within the Metadata Panel.
Photo of John R. Ellis

John R. Ellis, Champion

  • 4342 Posts
  • 1154 Reply Likes
And regarding your goal of setting a batch of scanned photos to have the same exact capture time, you can't do it in LR.  Please add your me-too vote and detailed opinion of why you want this to this feature request: https://feedback.photoshop.com/photoshop_family/topics/edit_capture_time_issue_need_a_way_to_set_all...

See Alan Harper's response for how to use a plugin to do this.
Photo of Ivo ter Horst

Ivo ter Horst

  • 1 Post
  • 0 Reply Likes
This reply was created from a merged topic originally titled Lightroom: Sort on capture date/time not applied when copy-paste of metadata with....

When I copy/paste the metadata (with capture date/time selected) of one photo to another photo (which didn't have any date/time set), the metadata is copied correctly, but the sorting of photos (sort on capture date/time) is not reapplied.

Manually changing the ordering does not seem to work. When switching back to 'order by capture date/time' the photo is still not put in the right position.

When changing the capture date/time via Metadata > Edit Capture Time, the photo is correctly reordered.

My expectation is that after pasting metadata, containing a new capture date/time, the photo would be reordered correctly.

I'm using Lightroom 6.12.
Photo of John R. Ellis

John R. Ellis, Champion

  • 4260 Posts
  • 1132 Reply Likes
In the original topic, Alan Harper wrote:

"This is a long-time issue in Lightroom. The only one of the dates you can edit in the metadata panel is not the one that Lightroom uses to sort by. Some of these metadata fields are supposed to be kept in sync, and by editing one of them, you break that rule too.

"My advice is to use the Metadata : Edit Capture Time command if it fills your needs. In this way, Lightroom has the ability to keep everything copacetic. If you still feel the need to copy/paste the capture time, then look at this post for a couple of ways to make it work."
Photo of John R. Ellis

John R. Ellis, Champion

  • 4260 Posts
  • 1132 Reply Likes
Photo of John R. Ellis

John R. Ellis, Champion

  • 4372 Posts
  • 1160 Reply Likes
Here's a recipe for reproducing the bug with photos that are missing EXIF:DateTimeOriginal:

1. Create a new catalog.

2. Download and unzip https://dl.dropboxusercontent.com/u/21811200/capture-time-bug.2017.08.21.zip

3. Import the three pics in the unzipped folder "capture-time-bug".

4. Select All Photographs and do View > Sort > Capture Time and View > Sort > Ascending.

5. Observe the following inconsistent ordering of pics:



Inconsistency A: The pics are not ordered by the capture date/time shown under the thumbnails.  

Inconsistency B: The date/time shown under the test2.jpg thumbnail doesn't match the capture date/time shown for that file in the Metadata panel.

Inconsistency C: The Metadata > Default tagset shows a capture date/time (see the screenshot above), while the EXIF tagset shows no Date Time Original and the IPTC tagset shows no Date Created:




(The Metadata Working Group spec calls for EXIF:DateTimeOriginal and IPTC:Date/TimeCreated to match.)

The proximate cause of these symptoms is that test2.jpg has EXIF:ModifyDate but no EXIF:DateTimeOriginal.  This often occurs when importing scans and other images not produced by digital cameras.

This post, among others, discusses the underlying architectural problem in LR: https://feedback.photoshop.com/photoshop_family/topics/lightroom-still-inconsistent-capture-date-tim...
Photo of John R. Ellis

John R. Ellis, Champion

  • 4372 Posts
  • 1160 Reply Likes
This was tested on LR CC 2015.12 / OS X 10.12.6.
Photo of John R. Ellis

John R. Ellis, Champion

  • 4372 Posts
  • 1160 Reply Likes
This bug was fixed in LR 7, but see here for a related bug that was introduced: https://feedback.photoshop.com/photoshop_family/topics/lightroom-still-inconsistent-capture-date-tim...
Photo of John R. Ellis

John R. Ellis, Champion

  • 4372 Posts
  • 1160 Reply Likes
Here's a recipe for reproducing the bug with editing IPTC > Date Created in the Metadata panel or using Metadata > Copy/Paste Metadata to copy IPTC > Date Created. This was tested in both CC 2015.12 and LR 5.7.1, OS X 10.12.6 (i.e. this behavior has been present since at least LR 5.7.1):

1. Create a new catalog.

2. Download and unzip https://www.dropbox.com/s/6b0s00up2i7lm04/iptc-date-bug.2017.08.21.zip?dl=0

3. Import the three pics in the unzipped folder "iptc-date-bug".

4. Select All Photographs and do View > Sort > Capture Time and View > Sort > Ascending.

5. Observe that the pics sort in order test1.jpg, test2.jpg, test3.jpg:



6. Observe that for test1.jpg and test2.jpg, the date under the thumbnails match the capture date/time shown in Metadata > Default, Metadata > EXIF > Date Time Original, and Metadata > IPTC > Date Created.

7. Observe that for test3.jpg, there is no capture time shown in Metadata > Default, and Metadata > EXIF > Date Time Original and Metadata > IPTC > Date Created are blank.

8. Select test2.jpg, and in the Metadata > IPTC panel, change Date Created to 2014-08-21T14:04:51.  Do the same for test3.jpg.

9. Observe that the various dates shown for test2.jpg and test3.jpg are inconsistent:

test2.jpg:
Thumbnail: 8/21/16 (wrong)
Metadata > Default > Capture Date: 8/21/16 (wrong)
Metadata > EXIF > Date Time Original: 8/21/16 (wrong)
Metadata > IPTC > Date Create: 8/21/2014 (correct)

test3.jpg:
Thumbnail: 8/21/14 (correct)
Metadata > Default > Capture Date: 8/21/16 (wrong)
Metadata > EXIF > Date Time Original: (wrong)
Metadata > IPTC > Date Create: 8/21/2014 (correct)

The Metadata Working Group's "Guidelines for Handling Image Metadata Version 2.0", which Adobe employees have previously stated controls LR's metadata behavior, requires that all three date/time fields match after one of the fields is changed.

10. Observe that the pics are no longer correctly sorted by the dates shown under their thumbnails:



11. Select all three pics and do Metadata > Save Metadata To File.

12. In a command shell, execute this command:

exiftool -a -G -exif:datetimeoriginal -xmp:datecreated -iptc:datecreated test2.jpg test3.jpg

Observe this incorrect output:
======== test2.jpg
[EXIF]          Date/Time Original              : 2016:08:21 14:04:51
[XMP]           Date Created                    : 2014:08:21 14:04:51
[IPTC]          Date Created                    : 2014:08:21
======== test3.jpg
[XMP]           Date Created                    : 2014:08:21 14:04:51
[IPTC]          Date Created                    : 2014:08:21
Note that in test2.jpg, EXIF:DateTimeOriginal doesn't match XMP:DateCreated and IPTC:DateCreated. Also note that in test3.jpg, there is no EXIF:DateTimeOriginal.

However, the "Guidelines for Handling Image Metadata Version 2.0" requires that in each file, all three fields should exist and contain the same value.

This post, among others, discusses the underlying architectural problem in LR: https://feedback.photoshop.com/photoshop_family/topics/lightroom-still-inconsistent-capture-date-tim...

LR should maintain internally a single field representing "capture time", and it should use the Metadata Working Group's rules for mapping that field to and from the EXIF, XMP, and IPTC date fields in the file and to and from the Edit Capture Time command and the Metadata panel > IPTC > Date Created field.
(Edited)
Photo of 570E

570E

  • 4 Posts
  • 1 Reply Like
Is there some other adobe product that does do a good job with capture time and date? If not, is there some other software that does?
Photo of John R. Ellis

John R. Ellis, Champion

  • 4372 Posts
  • 1160 Reply Likes
LR 7.0.1 (Classic) fixes the bug with photos that have EXIF:DateTime but no EXIF:DateTimeOriginal. (ExifTool calls EXIF:DateTime EXIF:ModifyDate.)  The recipe for reproducing that bug is here: 
https://feedback.photoshop.com/photoshop_family/topics/lightroom-still-inconsistent-capture-date-tim...
Photo of John R. Ellis

John R. Ellis, Champion

  • 4372 Posts
  • 1160 Reply Likes
Note that LR 7 fixes problems with newly imported photos.  Photos imported prior to LR 7 still need to be adjusted using the workaround described above:  Select the affected photos, do Metadata > Edit Capture Time, and do Change All.
Photo of John R. Ellis

John R. Ellis, Champion

  • 4372 Posts
  • 1160 Reply Likes
Unfortunately, LR 7.0.1 doesn't properly handle photos with neither EXIF:DateTime nor EXIF:DateTimeOriginal, e.g. photos from many scanner programs.  I think this bug was previously fixed in later versions of LR 5 and early versions of LR 6 (the last time I recall testing it).   (Note that ExifTool calls the industry-standard EXIF:DateTime "ModifyDate".)

Here's how to reproduce the bug:

1. Create a new catalog.

2. Download and unzip https://www.dropbox.com/s/hbma8x3n15n99ce/capture-time-bug.2017.11.13.zip?dl=0

3. Import the file "test4.jpg".

4. Observe that the date/time shown under test4.jpg's thumbnail is the file's last-modified time incorrectly expressed in UTC rather than local time.  (My computer is in UTC-8.):



5. Do View > Sort > Capture Time and View > Sort > Ascending and observe that the photos are correctly sorted by the date appearing under the thumbnail:



6. Do Metadata > Edit Capture Time and observe that "Original Time" shows the file's last-modified time in local time,  which doesn't match the date/time shown under the thumbnail (UTC). Hit Cancel when done.



7. Do View > Show Filter Bar and select Metadata. With test4.jpg selected, observe that the Date column shows test4.jpg in the year 2017, even though the Metadata panel's Default tagset incorrectly shows no capture date.  To be consistent with the handling of photos with EXIF:DateTime but no EXIF:DateTimeOriginal, the Metadata panel should show test4.jpg's file last-modified time as Capture Date/Time.



8. Select test4.jpg and do Library > Rename Photo.  Select the Capture Date template.  Observe that the file gets renamed using the file's last-modified time in local time, which doesn't match the UTC time shown under the thumbnail:

 

To summarize the inconsistencies:

A. The date/time shown under the file's thumbnail is the file's last-modified time shown in UTC rather than local time.

B. The Edit Capture Time command's Original Time correctly shows the file's last-modified time in local time, which doesn't match the UTC time shown under the thumbnail (incorrect).

C. The Metadata panel incorrectly shows the photo with no Capture Date, whereas the Metadata browser of the Library Filter bar correctly shows the capture date as "known".

D. Renaming the file using the capture date correctly uses the last-modified time as expressed in local time, whereas the date shown under the thumbnail is incorrectly shown in UTC.
Photo of John R. Ellis

John R. Ellis, Champion

  • 4372 Posts
  • 1160 Reply Likes
LR 7.0.1 doesn't fix the outsanding bug with editing IPTC > Date Created in the Metadata panel or using Metadata Copy/Paste Metadata to copy IPTC > Date Created: https://feedback.photoshop.com/photoshop_family/topics/lightroom-still-inconsistent-capture-date-tim...
Photo of ABHISHEK KUMAR

ABHISHEK KUMAR, Employee

  • 38 Posts
  • 17 Reply Likes
We are able to reproduce the inconsistency observed in the capture date/time for the images attached by John. We have logged a new bug for the same. 
Photo of John R. Ellis

John R. Ellis, Champion

  • 4345 Posts
  • 1156 Reply Likes
Good, thanks.
Photo of Sunil Bhaskaran

Sunil Bhaskaran, Official Rep

  • 412 Posts
  • 147 Reply Likes
Please see Lightroom Classic 7.1. This issue is fixed.

Thanks,
Sunil
Photo of Linda Knapp

Linda Knapp

  • 1 Post
  • 0 Reply Likes
The issue is not fixed in 7.1 - or at least if it was  it is back in 7.3....
Photo of Alison Castle

Alison Castle

  • 9 Posts
  • 0 Reply Likes
Not sure if my issue is the same as others who have posted here, but I'm dealing with a large-scale nightmare relating to creation dates in my LR catalog of 20K+ images. I recently made a lot of keyword updates and saved the metadata to the files. Then I noticed that for any of my photos that didn't have embedded capture/digitized metadata, the "Metadata Date" was changed to the day I saved the keyword metadata to the files. These files now only show the new date in the metadata since they lack capture dates. 

However, in Library grid view, the thumbnails still display the correct creation dates even though in the metadata panel all date fields are empty except for Metadata Date. So when I followed the advice of someone above to save metadata to file and then read metadata from file, I ended up wiping the correct capture date that had been displayed on the thumbnail, replacing it with the date I last edited the metadata.

If there is no way to reset the capture times to those saved in the LR catalog (i.e. the ones displayed on the thumbnails), then I'm facing hundreds of hours of manually correcting the metadata. In other words, nightmare.

I have my entire LR library synced/backed up on Dropbox. It is possible to restore a previous version from Dropbox, but this is only possible on a file-by-file basis. I'm now regretting not backing up my library to my Time Machine.
Photo of Mikkel Saatvedt Dahr

Mikkel Saatvedt Dahr

  • 2 Posts
  • 1 Reply Like
Maybe it is obvious that this will not work, but could you restore a previous version of the catalog? Before you made the edits? 

Im horrified by the thought of your situation. Hope you encounter a fix!
Photo of Alison Castle

Alison Castle

  • 9 Posts
  • 0 Reply Likes
I could, but that would not solve the problem because LR wrote the metadata to the original files.
Photo of John R. Ellis

John R. Ellis, Champion

  • 4279 Posts
  • 1138 Reply Likes
Not the same issue as the topic in which you posted.

Please reference the new conversation here: Lightroom: Recovering file last-modified date/time?