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

[John R Ellis]

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-tim....  

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

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". Untitled2_inline-402b28f5-7fce-4485-bbc7-1eba2e9ee1ed-622028544.png Untitled_inline-a0d82271-2553-4a54-8824-20de68939af3-906850541.png

[Beany from Brooklyn]

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.

[ItWasNotMe]

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.

[ItWasNotMe]

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

[ItWasNotMe]

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...

[ItWasNotMe]

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.

[ItWasNotMe]

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...

[alanterra]

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:

[John R Ellis]

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.

[alanterra]

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.

[ItWasNotMe]

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..... 

[John R Ellis]

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).

[ItWasNotMe]

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.

[FeedbackCommunityMember]

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.

[BassBone42]

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. 

[FeedbackCommunityMember]

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.

[Victoria Bampton LR Queen]

Check you're actually running the latest version (2015.8) as this sounds a lot like a bug that was fixed months ago.

[FeedbackCommunityMember]

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??

[John R Ellis]

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

[FeedbackCommunityMember]

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.

[John R Ellis]

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.)

[FeedbackCommunityMember]

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.

[alanterra]

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.

[FeedbackCommunityMember]

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

[alanterra]

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.

[FeedbackCommunityMember]

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.