LR displaying incorrect "Date Time Digitized" for video clips

[ted939]

LR Classic version 11.4.1 is displaying incorrect "Date Time Digitized" for video clips on my Mac (OS 12.4 Monterey).

When I offload video clips from my iPhone 13 Pro (iOS 15.6) to my Mac (OS 12.4 Monterey), Finder displays the correct date/timestamp.

BUT once I then import those video clips in to LightRoom Classic (version 11.4.1), LR displays an errant date/timestamp that is 7 hours later than the correct timestamp (i.e. Finder displays correct timestamp of 1:49pm, while LR displays INcorrect timestamp of 8:49pm).

This happens whether I brought the clips from iPhone to 13 directly via LR's Import function, or from first Airdropping from iPhone to computer and then importing those files already on computer into LR.
How do I fix this problem?

Thanks!

[johnrellis]

Are the times correct in the EXIF Metadata panel's Date Time Original?  Date Time Original is when the shutter was pressed, while Date Time Digitized is when an analog version was converted to digital form (e.g. when a negative was scanned).  In your case, Date Time Original and Date Time Digitized should be the same.

[ted939]

Hi John, thanks for your reply!

There is no "Date time Original" in the EXIF section:

The "Date Time Digitized" does match the timestamp on my image on my iPhone.

Note that the "Date Time" is when I imported into LR

[ted939]

I don't see any way to delete or edit my previous reply from just a couple minutes ago.

I meant to write that the "Date Time Digitized" does NOT match the timestamp on my image on my iPhone (which is the issue I first wrote about).

[johnrellis]

"LR displays an errant date/timestamp that is 7 hours later than the correct timestamp (i.e. Finder displays correct timestamp of 1:49pm, while LR displays incorrect timestamp of 8:49pm)."

Are you in a time zone seven hours later that UTC (GMT), e.g. PDT on the US west coast?

iOS devices are one of the few for which LR actually gets the time zone of video correct. But for some reason, it's not getting it right for video produced by your iPhone 13.   

As a next step, take a very short sample video (less than 49 MB) that shows the problem and attach it to your reply here. I can put it under the microscope and examine its metadata to see what might be going wrong.

[ted939]

Here you go, John, a 5-second clip.

Finder shows the accurate Aug. 14, 2022 at 1:25pm, but LR shows inaccurate Aug 14 at 8:25pm.

Thanks,

Ted

[ted939]

Yes, I'm in PDT (US West coast).

[johnrellis · Accepted solution]

That sample video contains the industry-standard QuickTime:CreateDate metadata field:

[QuickTime]     Create Date                     : 2022:08:14 20:25:05

The poorly defined QuickTime standard defines that field to be in UTC but provides no way to specify the time zone.   But traditionally, most cameras (other than smart phones) have ignored the standard and written local time into CreateDate, and so LR interprets it as local time (8:25:05 pm PDT).

Apple and Android smart phones, with Internet-synchronized clocks, obey the standard and write UTC times into Create Date.  Apple devices also write the date/time with a time zone into an Apple-specific, non-standard field, CreationDate:

[QuickTime]     Creation Date                   : 2021:11:08 06:45:07-05:00

For years, LR ignored that field, because Adobe's legal department considers any field not part of an industry standard as "proprietary", requiring contractual permission from the manufacturer before an Adobe app can read it.   Finally, after many years of complaints, Adobe finally got permission from Apple to read it.  (I don't know of any other company using that legal interpretation.)

Your sample video comes from an Apple device but was created by the Filmic app, not the built-in camera app.  It doesn't contain a QuickTime CreationDate field (with the time zone), just the standard CreateDate, so LR interprets the time as local time (7 hours off), even though in fact it is in UTC.  

You could ask the Filmic app developers to add the CreationDate field, though I'm not sure whether LR checks for other fields as well to ensure the file was created by Apple software (e.g. camera model).

The reason you see the correct time in Finder is that it is showing you Date Modified and Date Created, which are set by the operating system (or camera firmware) when the file was first created and then modified, and they all agree on the interpretation of those times.   In general, photo and video apps don't rely on those times because in general they aren't preserved as different apps and services manipulate the file.

But as a workaround in this case, after importing the videos, you can do the LR command Metadata > Edit Capture Time and select Change To File's Creation Date (which Finder displays as Date Created).  That will change LR's internal notion of capture date to the file's Date Created shown in Finder.  (But note that LR won't write that changed date back into the video or in exported copies.)

[ted939]

Thanks for all that great info, John.

Yes, I had considered that I could change LR's internal timestamp, knowing that it doesn't actually change the file's timestamp (but wishing it would).  I was just hoping that there was a way to get LR to display the correct timestamp without me having to do that.   

Thanks!