John_R_Ellis's profile
Champion

Champion

 • 

5.8K Messages

 • 

100.4K Points

Wed, Dec 10, 2014 12:38 AM

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

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

Responses

4 Messages

 • 

112 Points

4 y ago

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?

Champion

 • 

5.8K Messages

 • 

100.4K Points

3 y ago

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

Champion

 • 

5.8K Messages

 • 

100.4K Points

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.

Champion

 • 

5.8K Messages

 • 

100.4K Points

3 y ago

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.

Champion

 • 

5.8K Messages

 • 

100.4K Points

3 y ago

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

42 Messages

 • 

866 Points

3 y ago

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. 

Champion

 • 

5.8K Messages

 • 

100.4K Points

Good, thanks.

Adobe Administrator

 • 

538 Messages

 • 

9.9K Points

Please see Lightroom Classic 7.1. This issue is fixed.

Thanks,
Sunil

1 Message

 • 

62 Points

The issue is not fixed in 7.1 - or at least if it was  it is back in 7.3....

9 Messages

 • 

154 Points

3 y ago

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.

3 Messages

 • 

102 Points

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!

9 Messages

 • 

154 Points

I could, but that would not solve the problem because LR wrote the metadata to the original files.

Champion

 • 

5.8K Messages

 • 

100.4K Points

Not the same issue as the topic in which you posted.

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

Champion

 • 

5.8K Messages

 • 

100.4K Points

3 y ago

Sunil and Melissa,

In August, Adobe asked me to provide recipes for the issues in this thread. I provided two such recipes, updated the first post in this topic with them, and communicated that by email. After 7.0.1, Adobe asked me to test, which I did, I updated one of the recipes, and posted that the other one hadn't yet been addressed.

In LR 7.1, the recipe concerning photos missing metadata capture date/times has been completely addressed, while the recipe concerning edits to IPTC:DateCreated has not.

Details:

This topic concerns two ways to provoke the underlying architectural inconsistency in the capture date/time fields, in which the values shown under the thumbnail, in Metadata > Default, Metadata > EXIF, and Metadata > IPTC would be inconsistent, and different parts of the application would use different values (sorting, file renaming, the Library filter bar, smart collections).

1. Import a photo or video with missing metadata date/time fields or with just EXIF:DateTime but not EXIF:DateTimeOriginal (e.g. importing scans or from very old digital cameras):

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

I've tested this recipe and tested a similar one for video, and it appears to be finally fixed!   There are no inconsistencies between the dates shown under the thumbnail and in Metadata > Default and Metadata > EXIF.  Sorting thumbnails in grid view and the Library Metadata filter bar are consistent with those values, and renaming files in grid view and in export uses those values consistently.  

2. Change IPTC:DateCreated with with the Metadata > IPTC panel or by copying and pasting that field with Metadata > Copy/Paste Metadata.  

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

Though the Metadata Working Group specification to which LR subscribes says that IPTC:DateCreated should be consistent with EXIF:DateTimeOriginal and XMP:DateCreted, changing the IPTC:DateCreated in the Metadata panel doesn't update the date/times shown under the thumbnail, Metadata > Default, or Metadata > EXIF.

The previous workaround continues to work: Select all the affected photos and doing Metadata > Edit Capture Time and then Adjust All will set IPTC:DateCreated to the same value as shown in Metadata > Default and Metadata > EXIF.

Champion

 • 

5.8K Messages

 • 

100.4K Points

3 y ago

"should you use a plug-in then you are at the mercy of the gods as to which of the many fields the developer has chosen."

The LR SDK API appears to reflect accurately what is shown in the application to the user.  All photos have a "captureTime" that is the same as what's shown in the app, and photos that have EXIF:DateTimeOriginal in their metadata have "dateTimeOriginal".

{--table: 1
    [LrPhoto( id "3875" )] = {--table: 2
        captureTime = 461908947, 
        date = "2015-08-22T04:02:27", 
        path = "/Users/john/Downloads/capture-time-bug copy/test2.jpg"}, 
    [LrPhoto( id "3874" )] = {--table: 3
        captureTime = 493531347, 
        date = "2016-08-22T04:02:27", 
        dateTimeOriginal = 493531347, 
        path = "/Users/john/Downloads/capture-time-bug copy/test1.jpg"}, 
    [LrPhoto( id "3876" )] = {--table: 4
        captureTime = 556603347, 
        date = "2018-08-22T04:02:27", 
        dateTimeOriginal = 556603347, 
        path = "/Users/john/Downloads/capture-time-bug copy/test3.jpg"}, 
    [LrPhoto( id "3877" )] = {--table: 5
        captureTime = 532143432, 
        date = "2017-11-12T01:37:12", 
        path = "/Users/john/Downloads/capture-time-bug copy/test4.jpg"}}

84 Messages

 • 

1.1K Points

Fortune favours the lucky then...

 Lets conduct a little thought experiment. Conjecture:

  • There is a field captureTime in the Database table, but not all of the code uses this (maybe its seen as slow to access, who knows)
  • There are two fields in the XMP, exif:DateTimeOriginal and photoshop:DateCreated,  (in reality there are more but twos enough for this example) and these are used frequently in the code but not consistently, which is the symptom we see

 We know that ‘Copy/Paste’ metadata and ‘Edit Capture Time’ don’t update consistently, so

  • Lets say ‘Edit’ updates all three
  • Lets say ‘Copy’ only updates photoshop:DateCreated and (maybe) captureTime but not exif:DateTimeOriginal
  • So, we have some images for which these two xmp values may differ 

Now, there are lots of places that capture date is used.

  • Several points in the library display (i.e. the inconsistencies in the title of this thread)
  • Sort by
  • The API
  • The edit and copy functions themselves need to display something as a starting point
  • And so on
There is no guarantee that all of these use captureTime, or exif:DateTimeOriginal. From you example they can't, otherwise we would not see variability. In V6 for example some of the fields had quite complex conditional statements trying to find a date that could be displayed.

Lets have Adobe ‘fix’ the immediate problem and have the ‘Copy’ write exif:DateTimeOriginal as well (and captureTime if it doesn't). Further, it doesn't standardise the code to use the value in the database rather than the XMP and doesn’t provide any utility function to align these values for each image. 

Were this the case, then

  • At any point in the future, any of its developers may decide that for the little fragment of code they are changing, it would be better to use the ‘other’ field.
  • Then for some data stored prior to the ‘fix’, we are back to the inconsistency and start all over again. This is why it should repair the database as well as fixing the code.

 There is a reason that camera supports have three legs and not four – stability.

 For the same reason its poor practice to have the same data value in more than one place.

Champion

 • 

5.8K Messages

 • 

100.4K Points

I agree that the current architecture is very fragile.   Some background: I believe that it was originally motivated by a desire to have the database metadata tables reflect the contents of the corresponding date/time metadata fields. (There are four different photo metadata standards with at least 12 different date/time fields.)  Several years after LR was released, the Metadata Working Group came out with its revised standard, which LR adopted.  That standard introduced some significant changes in the way that the multiple date/time metadata fields should be handled.   

It would be straightforward for LR to have its cake and eat it too, maintaining the original metadata fields in the database but have a single unified method for accessing "capture time" (whether via a function or a database field).  But somewhere along the way the engineering lost its way on this.

84 Messages

 • 

1.1K Points

Yep, its often referred to as data abstraction, dates back to before 1980 as a concept.

Sadly, though, I think swathes of the code don’t use ‘the database’ per se, rather they parse the xmp string. This is always stored as a composite string in one of the columns. For example, if my analysis below is correct, then

  • ‘Edit Capture Time’ doesn’t take the ‘true’ database field as the source
  • Reminder, Paste didn’t set this field, therefore if ‘Edit’ used this as the source then it would revert the date back to the value before the paste, rather than ‘correcting’ the issue
  • Conclusion, ‘Edit’ must be taking photoshop:DateCreated as its source
  • This is only in the xmp

 Another rather old concept is refactoring, Wiki suggests first known use of the term is 1990.

 In this context, you might refactor the code and make all the ‘read’ occurrences of capture date use the 'true' database field and apply data abstraction to the write occurrences.            Removes some inconsistency but highlights another problem, the 'true' database field can be incorrect.

Adobe Administrator

 • 

538 Messages

 • 

9.9K Points

3 y ago

Thanks a lot for the details, John.
We are looking into the second issue you mentioned.

Thanks,
Sunil

84 Messages

 • 

1.1K Points

This is what I think is happening

On a test catalog  I took three images created in 2010, 2014, 2017 from a supported camera

 ·      2010 image, I left unchanged

·      2014 image, I pasted the date from the 2010 image

·      2017 image, I used Metadata -> Edit Capture time; set to random value

First difference:

Paste metadata doesn’t write to the field captureTime in Table Adobe_Images

Action, Copy/Paste from 2010 image to the 2014 image

  • Before "2014-04-25T14:09:38.24", After "2014-04-25T14:09:38.24"

Whereas Metadata -> Edit Capture time does, on the 2017 Image

  • Before, "2017-03-28T11:53:38.41, After "1995-01-01T00:00:01"

Second difference:

Only image related xmp date field that I could see copy/paste changing is photoshop:DateCreated

These are selected changes on the Copy/Paste xmp, three of the values are unchanged from their original 2014 values (created in import)

  • exif:DateTimeOriginal="2014-04-25T14:09:38.24"
  • xmp:ModifyDate="2014-04-25T14:09:38.24"
  • xmp:CreateDate="2014-04-25T14:09:38.24"
  • photoshop:DateCreated="2010-01-01T12:22:19.73

Whereas the Edit Capture Time changes an additional field, exif:DateTimeOriginal

  • exif:DateTimeOriginal="1995-01-01T00:00:01"
  • xmp:ModifyDate="2017-03-28T11:53:38.41"
  • xmp:CreateDate="2017-03-28T11:53:38.41"
  • photoshop:DateCreated="1995-01-01T00:00:01" 

Note, neither action changes the xmp:CreateDate, or xmp:ModifyDate both are the time that I shot the relevant image.

[Edit] Forgot to say there are other date fields in the tables that I didn't look at, such as harvested date which may or may not have been updated.

106 Messages

 • 

1.7K Points

I was hopeful that Lightroom Classic CC 7.1 would fix this issue, but it didn't.  I have updated to 7.2 and still have the same problem, but only with iphone 6s plus videos (.MOV).  

When I import videos and images I like to rename all my files to include the capture date and time (YYY-MM-DD Hour.Minute.Second).  My 5d Mark iv images and videos (.MOV) import and rename based on time perfectly and it matches all the metadata times.  Same with iphone images.  However, the time in the iphone video filenames are ALWAYS wrong, and I can't for the life of me figure out where the hour even comes from.  It's always 5 or 6 hours off, which I suspect changes based on whether it's daylight savings or not.  As a result of the incorrect time, any videos taken after 6 or 7 pm, also have an incorrect date.

To be clear, I am expecting a filename based on the time CREATED, just like images and other videos I import.  

Example 1-iphone 6s plus:
Filename time: 14.22.28 (=2:22:28 pm; 6 hours off when daylight savings ends)
Date Time Digitized: 8:22:28 AM (correct time of capture)
Date Time: 10:37:17 PM (correct time of import)

Example 2-iphone 6s plus:
Filename time: 23.43.57 (=11:43:57 pm; 5 hours off during daylight savings)
Date Time Digitized: 6:43:57 PM (correct time of capture)
Date Time: 9:48:41 PM (correct time of import)

At first glance I might have said it was a time zone error, except the metadata is correct in the videos and all other images and my professional camera videos renamed with the same filename structure are always correct upon import, with the filename date/time matching all metadata.  

Observations:
*Images have 3 date/time areas; all seem to match; all are the exact date/time created:
1) Date Time Original     =date/time created
2) Date Time Digitized    =date/time created
3) Date Time                      =date/time created

*However, Videos only have 2 & 3 of the above time areas where:
2) Date Time Digitized   =date/time created
3) Date Time                     = date/time IMPORTED (WHY anyone needs this is beyond me, but whatever, even this doesn't match the random time in my iphone video filenames)

*Sorting images/videos by date created works correctly-even when the filename shows an incorrect time.  I presume this is because the metadata is correct, regardless of the filename.

*Auto importing the exact same iphone videos as above  from a watched folder and using the exact same naming structure (date hour.minute.second) works correctly.  I've been using this workaround for years.  But it is full of flaws: Lightroom will re-import the same files-with the exact same metadata- if air dropped to the watched folder by accident. And it is a pain to figure out what has and hasn't been airdropped if done out of order, so my catalog becomes full of duplicate images and videos that have a -2 at the end of the filename).  

This is a HUGE problem.  My workaround is flawed and it causes me to not back up my iphone images as often as I should.  Even when I don't import using the hour.minute.second filename structure, the date is off for all iphone videos taken after 6pm or before 6am, which is UNACCEPTABLE for organizational purposes.  Ultimately, I can't believe this has been going on for years and people just accept it.  I pay every month and I haven't been able to import videos with the correct time.  That's basic.  FIX IT.   

Note:  I have also tried renaming on import with only the date and without the time, but this still results in incorrect dates for all videos taken after 6 or 7 pm.  Not renaming with dates is not an option.

495 Messages

 • 

10.5K Points

Hi Laura. I understand your frustration, but if you are looking for a work-around while you are waiting for a fix, i suggest you look at A Better Finder Rename. You can create droplets that use metadata to rename files, which you would apply before importing the video into Lightroom. (If you are on Windows, I suspect that there are umpteen utilities that offer the same options.) I use A Better Finder Rename all the time.

106 Messages

 • 

1.7K Points

Thanks, Alan!

Actually, I received a helpful reply on another forum last night which had an easier (IMO) and effective workaround: 

Workaround:
1) Import iphone .MOV videos as you normally would.  (I use "YYYY-MM-DD Hour.Minute.Second_iphone" and use it to check against the metadata). 

2)  Select all previously imported files and, under the metadata tab, Click "Edit Capture Time".  Select Type of Adjustment: Adjust to a specified date and time.  Don't change anything.  It will appear nothing needs changing as the original time already matches the corrected time.  Select Change All.  You'll notice there is now a 3rd metadata date/time entry: Date Time Original.  This matches the metadata list of .CR2 and .jpg file and is CRITICAL in order for ALL .MOV files to be renamed correctly*.   

4) NOW select all files and rename your using a date/time preset.  I used the same one that I use upon import and it works.  The filename matches the date and time the video was TAKEN/Created (not imported).  This works for a single file or multiple files.

**Note: I tried skipping step 3 to see if it was necessary, and it IS.  Without editing the capture time the files were renamed using the IMPORTED date/time. In fact, when I tried renaming an .MOV file from my 5d Mark iv, which had the correct date/time in the filename upon import, it was renamed using the IMPORTED date/time also.  This must be ANOTHER BUG on top of the bug that randomly adds 5-6 hours (for CST) to the Date Time Digitized.  The renaming feature must use the "Date Time" metadata (which is the IMPORTED date/time) if there is no "Date Time Original" metadata entry.  So stupid.  Therefore, step 3 is necessary in order to create the "Date Time Original" metadata entry, which eliminates the mis-naming in all video files.  

Hope that helps!  But also hope it gets fixed!!

2 Messages

 • 

72 Points

3 y ago

This reply was created from a merged topic originally titled Lightroom: Inconsistent times.

Testing.

68 Messages

 • 

916 Points

3 y ago

This reply was created from a merged topic originally titled Lightroom Classic: Sort by capture time bug (scans and raws).

Not sure whether this is relevant, but a similar problem occurs with scanned tiff images interspersed with camera taken pictures. In other words, scan some pictures as tiff and import Imp light room, then import pictures .ARW files, and then scan some more pictures as tiff. The new tiff images cluster with the older tiff files, and will come before the ARW files. In this situation there is no THM file.

Note: This conversation was created from a reply on: Lightroom Classic: Sort by capture time bug.

Champion

 • 

5.8K Messages

 • 

100.4K Points

The original merged topic contains details about Steven's symptoms (thanks!).  See the next post in this topic for a diagnosis.

Champion

 • 

5.8K Messages

 • 

100.4K Points

Steven, you can delete the Dropbox folder -- the recipe in the next post quickly reproduces the symptoms you observed.

Employee

 • 

295 Messages

 • 

7.8K Points

Steven,

I was able to reproduce your issue. We are looking into this.

Thanks,
Smit Keniya
Lightroom Classic CC Team

Champion

 • 

5.8K Messages

 • 

100.4K Points

3 y ago

Unfortunately, there is still a bug with the capture times of imported files missing EXIF:DateTimeOriginal (e.g. scans) -- the sort order in grid view doesn't always match that implied by the capture time shown under the thumbnails and in the Metadata panel.   LR sets the capture time of each scan to the file's modified time, but the internal catalog field used for sorting gets set n hours earlier, where is the UTC offset of the computer's time zone. 

To reproduce:

1. Create a new catalog.

2. Download and unzip this folder: 
https://www.dropbox.com/s/gkytf55c88vrm8k/capturetimebug.2018.05.17.zip?dl=0

3. Run these ExifTool commands to set the file modification dates of "before.jpg" and "after.jpg":
exiftool -filemodifydate="2001:05:01 h:01:00" before.jpg
exiftool -filemodifydate="2001:05:01 h:03:00" after.jpg
where = 15 - the UTC offset of your computer's time zone. My computer is in PDT (UTC - 7), so I set h to 8:
exiftool -filemodifydate="2001:05:01 08:01:00" before.jpg
exiftool -filemodifydate="2001:05:01 08:03:00" after.jpg
4. Import "before.jpg", "test.jpg", and "after.jpg" using Add (not Move or Copy).

5. In Library, select All Photographs and View > Sort > Capture Time.

6. Observe that the sort order of the photos is inconsistent with the capture times shown under the thumbnails and in the Metadata panel:



LR sets the visible capture time of each scan to the file's date-modified time expressed in the local time zone, but it sets the hidden internal field used for sorting to the date-modified time expressed in UTC.

The usual workaround fixes this: Select all the photos, do Metadata > Edit Capture Time, and click Change All.

Employee

 • 

295 Messages

 • 

7.8K Points

Hi John,

When I downloaded the zip and checked the filemodifydate for before and after.jpg, I am getting the following 
before.jpg - 2018:05:17 22:15:08+05:30
after.jpg - 2018:05:17 22:15:08+05:30

Also for the test.jpg file is as follows:
2018:05:17 22:15:08+05:30
and I have value for DateTimeOriginal as follows
2001:05:01 15:02:00

DateTimeOriginal value is only present in test.jpg

Here is the screenshot from the Lightroom Classic:


PS - I was testing on Win10

Thanks,
Smit

Champion

 • 

5.8K Messages

 • 

100.4K Points

To observe the bug, you need to run the ExifTool commands in step 3 before importing the files.

Champion

 • 

5.8K Messages

 • 

100.4K Points

Also, if you are located in a time zone whose offset is not a whole number of hours, it might be easiest to temporarily change your computer’s time zone to, say, UTC - 7:00.

Employee

 • 

295 Messages

 • 

7.8K Points

My Apologies. I misread your step.

Based on your suggestion, when I changed the TimeZone to UTC -7, I was able to reproduce the issue. I will update this to our bug.

Also, if I just use the date-time values you have shared, I am still able to reproduce this when reset my Laptop to IST - UTC +5:30

Thanks again for following up on this for such a long time!

Thanks,
Smit
Lightroom Classic CC Team

3 Messages

 • 

86 Points

3 y ago

This error starting appearing for me for a few months. Shot stuff on 17 June 2018 and some got sorted into the not-yet-happened 18 June folder. Checked the camera and made sure my settings were right too.

Champion

 • 

5.8K Messages

 • 

100.4K Points

Are you importing using a USB cable or by using a card reader?

3 Messages

 • 

86 Points

I use a card reader to import my files.

Champion

 • 

5.8K Messages

 • 

100.4K Points

OK, there's a separate bug with putting photos into the wrong folder that's triggered by importing with a cable.

1 Message

 • 

62 Points

2 y ago

I am running Lightroom Classic 8.0 on MacOS and noticed today that video files are still being wrongly renamed based on file Date/Time and not Creation Date/Time metadata, any idea how to fix it?

What is the exactly "field" that Lightroom uses as reference for renaming files?

27 Messages

 • 

420 Points

2 y ago

Hi


I’m having a similar problem here. After updating to the new version of LR classic Lightroom is incorrectly reading MTS video file capture times. The capture times for the same file in Adobe Photoshop, Adobe Bridge and Mac finder are all correct. Only in Lightroom is there a problem. It’s most annoying when I’m trying to filter files based on what year the photos and videos were shot. LR shows me files from 2015 when i’m trying to view files from 2017. The incorrect files all have the same incorrect capture time also. Very strange. I have about 50,000 so i’m Worried about files getting completely lost in the mix.The screenshots show the file info in Lightroom being incorrectly seen and then the file info in Photoshop being CORRECTLY seen. Any help would be greatly appreciated.