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

[John R Ellis]

As described in this topic, LR has a number of longstanding inconsistencies when handling video capture dates. Also, it doesn't handle Quicktime (.mov) capture dates very gracefully, which results in a time zone shift: http://feedback.photoshop.com/photosh...

[TheGreekGeek]

I just noticed my topic/bug was merged into this one. I feel this was done in error as my issue is specific to how LR is applying a file rename template. It's possible whoever did this only read my topics title and mistook my issue to be related to this thread.

As noted in my topic and the screenshots I linked, the capture time LR displays is correct. How it uses that time to generate my filename per my rename template is not. If the rename is performed at import it is correct (with the exception of MTS files) but if I apply a rename AFTER the import it shifts all my file names by 6 hours. The capture time remains correct.

To whoever merged my topic please undo this or. I specifically chose not to merge it into this topic as my problem is not the same as that as the OP's. I don't want my information pertaining to the rename functionality to be overlooked as I feel it offers some clues as to where the rename issue resides (i.e. works during import - for at least mov/avi files, fails for MTS - fails on subsequent renames). As a developer myself I know those sorts of clues could be very valuable. It took nearly 2 hours of testing to gather the details in my post and I now its been merged into a mostly unrelated thread where the information may get overlooked (especially given the age of this thread).

As you can see below the file reports a capture time of 6:05 PM. This is the correct capture time (it's dusk outside not midnight). What is incorrect is how LR chose to apply said capture time to the file rename template which generated a time 6 hours in the future. This issue was consistent across my entire catalog and always +6 hours off. As noted my workaround was to re-import my catalog and the problem went away for all but MTS files.


as you can see in the file system details (as posted in my org post) the capt time is correct. my issue is not related to OP; please unmerge

[TheGreekGeek]

John, is there anyway to find out who merged my topic into this one? My issue is related to the File rename functionality. The capture times I see are correct, it's how they're used that is a problem. (see my general comment below)

[John R Ellis]

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

[John R Ellis]

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

[Beany from Brooklyn]

Hi John,
How can I (or others) help gather info into one spot?
I always appreciate your help & insight!

[anothertal3]

Had some issues when attempting to assign the capture date/time of a video to its filename. There was always a strange offset.

I tried this workaround before renaming and it then worked fine.

Always worth a shot, I guess.

[anothertal3]

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 😕

[John R Ellis]

"Had some issues when attempting to assign the capture date/time of a video to its filename. There was always a strange offset."

If they were Quicktime videos (e.g. with extension .mov, from an iDevice), there's a known bug where LR gets confused by the time zone (or lack of one) stored in the video's metadata: http://feedback.photoshop.com/photosh...

[anothertal3]

Sorry, haven't been here for a while. Dropped by to thank you for suggestion.

Timezone handling seems to be kind of funny indeed, even with images.
Example: it  seems that any timezone stored in a picture (e.g. by Geosetter) will be removed when re-saving new meta information within Lightroom.

Then again... I'm not completely sure about the standardized process, so maybe it's some sort of irregular information anyway.

[John R Ellis]

"it  seems that any timezone stored in a picture (e.g. by Geosetter) will be removed when re-saving new meta information within Lightroom."

Yeah, LR doesn't follow the standard (Metadata Working Group, of which Adobe is a member), which calls for existing time zones in date/times to be preserved.   LR is pretty aggressive at pretending time zones don't exist.

[BassBone42]

This technique seemed to work more generally. I used it to fix both video and .JPG's that were sorting incorrectly. This was with Lightroom CC on a Mac. Thanks a bunch!

[ItWasNotMe]

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.

[John R Ellis]

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.

[ItWasNotMe]

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+

[ItWasNotMe]

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.

[ItWasNotMe]

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

[ItWasNotMe]

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

[John R Ellis]

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.

[John R Ellis]

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.  

[John R Ellis]

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

[ItWasNotMe]

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.

[ItWasNotMe]

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

[ItWasNotMe]

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.

[ItWasNotMe]

Well, I  didn't really expect a response, however much fun it was writing the comments :))