P: Inconsistent dates for files missing date/time metadata

I use the following workaround for video files that have the "right" capture time but the data used for date/time based file naming on import and sorting in grid view is incorrect. After import, filter for video files, and select all video files, select "Edit Capture Time" from the metadata drop down. Select "Adjust to specified time and date" this should be selected by default; leave the "original time" and "corrected time" windows untouched (you will see the correct time in both windows for the first video file in the batch, or maybe the most selected), then click on change. All the vidoes will be adjusted appropriately (to their own correct times) as a batch. I then rename the videos as a batch using my own date/time preset. So three steps to fix a batch. Video files from a different camera brand that have GMT as their capture time I use the above process but need to add the increment to GMT.

So, are you going to fix it? I can see now from this merged thread that you've been working on this for over a year.

The file's metadata contains an EXIF:ModifyDate field but not EXIF:DateTimeOriginal. The former indicates when the photo was last modified by the user (e.g. by editing), while the latter indicates when the photo was taken. It's curious that the phone added EXIF:ModifyDate but not EXIF:DateTimeOriginal.

It's also curious that LR decides to show EXIF:ModifyDate as the capture date, even though that's not what's recommended by the standards. It's doubly curious that it shows the file's modified time under the thumbnail in the grid view. But this is a symptom of a general problem that LR has when a file is missing DateTimeOriginal.

In Lightroom 4.3, an image's Library Grid label sometimes displays the File Creation time rather than the Capture time, even though the label option is set to "Capture Date/Time."

See attached screenshot. The image shown was captured (by a cellphone camera, alas, but with a correctly set clock) on Nov. 17 at 18:46, as correctly shown in the metadata. But the label in the grid shows the date as Nov. 23 at 00:54, which is the time I uploaded the image from the phone to my computer -- even though the Grid View option is Capture Date/Time, not Creation Date/Time. However, when sorting the Library Grid by Capture Time, the image correctly sorts in its time slot on Nov. 17. The sort order is correct, but the label is wrong.



The Edit Capture Time dialog also shows the "Original Time" (=capture time) correctly as Nov. 17 at 18:46 (actually, it shows Nov. 17 at 06:46, presumably because the image was taken 12 time zones away from my current location) and also gives the Creation Date as Nov. 23 at 00:54.



Interestingly, pictures taken with my real cameras have the correct Capture time showing in the grid. I see this incorrect behavior only with my cellphone camera. Clearly the phone is doing something wrong with its metadata, but the odd thing is that LR is reporting the Capture time correctly in the Metadata panel but incorrectly in the grid label. Shouldn't these be the same?

Until this gets fixed in LR, any ideas of external tools I might use on the metadata to trick LR to label the file correctly?

I just realized that the movies I import get sorted wrong and LR does not seem to know the creation date/time. They get sorted by the time they were imported. I then have to go in and individually select each one then go to metadata menu, time and have it change the time... WEIRD. I am now going thru 75 days of this to correct them all.
What is up? This is trivial because it works on my images perfectly and should do the same for videos.

I keep replicating the bug every day.

Photos are correctly sorted while movies just ignore DST / Time Zone.
In this case 1+1=2 hours. Movies are ordered along the photos as if they were shot 1+1=2 hours earlier.

This is quite easy to fix if only this is indeed the bug and any Adobe Employee reads these lines.

Still waiting for my thread to be split up again, I found the very same issue with some Sony DSC-RX100 videos.

They got ordered on Capture Time as if they were shot 2 hours earlier.
The very same bug for two completely different cameras. It can't be a coincidence!

I live on +1 GMT and now we're under DST, so exactly +2 hours.

Bug Report
Lightroom4 R2
System Information"Operating System new – server roles
System Model - White Box
Windows 7 Ultimate (x64) Service Pack 1 (build 7601)
Install Language: English (United States)
System Locale: English (United States)
Installed: 9/7/2011 1:50:04 PM No details available
Processor a Main Circuit Board b
3.00 gigahertz AMD Athlon II X4 640
512 kilobyte primary memory cache
2048 kilobyte secondary memory cache
64-bit ready
Multi-core (4 total)
Not hyper-threaded Board: ASUSTeK Computer INC. M5A88-V EVO Rev X.0x
Serial Number: MF70B6G08900555
Bus Clock: 200 megahertz
BIOS: American Megatrends Inc. 0402 04/18/2011
new USB Storage Use in past 30 Days (mouse over last used for details) new Hosted Virtual Machines (mouse over name for details)
Last Used
Maxtor Basics Desktop -- drive 3, s/n 2HBE66XP, rev 0125 4/30/2012 6:08:28 AM
Generic Flash Disk, s/n E150C44B, rev 8.07 4/23/2012 11:46:24 AM*
2.0 Flash Disk, s/n 216418592346, rev 4.00 4/19/2012 4:16:30 PM*
Maxtor OneTouch II, s/n B60EFY2H, rev 023d 4/16/2012 5:28:27 PM*

* Possibly used again before the reboot following this time.
None discovered
Drives new – drive encryption Memory Modules c,d
1230.17 Gigabytes Usable Hard Drive Capacity
630.57 Gigabytes Hard Drive Free Space

_NEC DVD_RW ND-3520A ATA Device [Optical drive]
ASUS DRW-24B3LT ATA Device [Optical drive]

Maxtor Basics Desktop USB Device [Hard drive] (750.15 GB) -- drive 3, s/n 2HBE66XP
ST3320413AS [Hard drive] (320.07 GB) -- drive 0, s/n 6VMW7WH3, rev JC45, SMART Status: Healthy
ST380011A [Hard drive] (80.03 GB) -- drive 2, s/n 4JV58LC8, rev 8.01, SMART Status: Healthy
ST380811AS [Hard drive] (80.03 GB) -- drive 1, s/n 9PS00AVH, rev 3.AAE, SMART Status: Healthy 12288 Megabytes Usable Installed Memory

Slot 'DIMM0' has 4096 MB
Slot 'DIMM1' has 4096 MB
Slot 'DIMM2' has 4096 MB
Slot 'DIMM3' is Empty
Local Drive Volumes new – volume encryption

c: (NTFS on drive 0) * 319.97 GB 236.73 GB free
d: (NTFS on drive 2) 80.02 GB 58.59 GB free
e: (NTFS on drive 1) 80.02 GB 65.66 GB free
h: (NTFS on drive 3) 750.15 GB 269.58 GB free

Situation/Condition:
Fully imported all photos on my photo drive.
Photo drive contains the Catalog and Cache Folders/Files
Folders arranged by shoot year/date
Files named by various useful names for me.
Year folders 2006 through 2012
Lightroom Library with Grid Mode
Sort by A-Z and Capture Date
Folders for years 2006 through 2011 all show in the grid as I would expect with the images sorted by Capture Date
Highlight the 2012 Folder with grid view order is miscellaneously sorted with the fires image in the upper left corner of the grid being
Select/Higliight the 20120102 Folder and all of the image files are properly sorted as expected by Created Date.

I deleted the Catalog and recreated/imported the image folders and files a second time creating a "new and clean" catalog with the same results. While I'm not the most experienced LR user; this does not seem to be O.K.

Hope you can solve the issue prior to full release.
Cordially,
Howard H. Heflin

Hi,

I'm evaluating Lightroom 4.1 and it is not useful for organize movie clip since all of the clips gets wrong "Capture Time". This also affects the import which I've set to rename the files based on the "Capture Time". I'm using a Canon S100. By the way the GPS data isn't read correctly either.

I've been using exiftool, which can read those fields, for renaming but I had expected Lightroom to be able to handle this as well.

The trick did actually work. It still doesn't explain why should Lightroom read time correctly for certain movies and wrongly for others. They have been shot with the very same settings. Metadata-wise they are identical.

What it seems to me (working with databases, locales, DST and so on), is that Lightroom may be internally adding +4 hours to the time for all the movies.

If you look carefully: >= 20.00 will become >= 00.00, while less than 19.59 will still remain <= 23.59. That would validate the strange (dis)order.
Some time ago I had a similar issue with certain SQL queries.

The trick did work, tried on a single file.