P: iPhone video Capture Time is shifted upon Import

I've encountered the same issue with my new Sony RX10 II - MP4 videos recorded with the XAVC S codec are shifted on import by 4 hours to match UTC. John R. Ellis has been a huge help in figuring out exactly what was happening and pointing me to this topic.

An update to my analysis above: 

Many cameras don't have a notion of time zone, and these cameras record their current time (usually local time) in the QuickTime/MP4 Create Date field.  For these cameras, it would be a mistake for LR to interpret the Create Date as UTC.

But newer cameras and phones do have a notion of time zone, and some of these (e.g. the iPhone and the Sony RX10 II) follow the original spec and record UTC in Create Date.  They may also record a time zone in an undocumented, manufacturer-specific field.

So there's no straightforward, practical way LR can figure out whether the Create Date field is in UTC or local time.

While using lightroom to import iPhone6 plus videos, the captured date/time are wrong and off by days sometimes(I have an example of a video who's meta data shows 12/27/2015 @ 4PM which is correct but lightroom shows 12/19/2015 @3:21:36 PM which is not correct) . Other times, the date is correct but the time is off by +8 hour for my videos taking in pacific standard time.

Thanks John. I hope Adobe addes a preference setting in Lightroom to allow shifting the UTC stored time back to the computer's local timezone offset. Seems like a simple solution and if made a preference, users could opt in/out of this setting. However, I'd think all would opt for this option.

Note that LR isn't actually shifting the time of the video, it's failing to shift the the UTC time that the iPhone records to local time. (See the post above: http://feedback.photoshop.com/photosh....)

The original sin is Apple's, defining a spec (Quick Time) that doesn't allow time zones to be recorded. Given that, there are a couple of possible fixes for LR:

1. LR could always shift the recorded UTC time to local time, which isn't perfect, since it wouldn't correctly handle videos taken in one time zone but uploaded to LR in another. But the most common case (videos taken in the same time zone as the computer) would be correctly handled.

2. LR could have a preference or option in the Import window for how to handle Quick Time videos.

Given that video metadata is in general highly incomplete and buggy, and has been ever since video was added to LR 4, I think it's unlikely that Adobe will ever address this. :-<

Adobe, why not offer a preference for those of us that want the import video time left alone, not shifted to GMT or UTC 0? I too am finding that when importing iPhone 6s videos to Lightroom CC 2015 I can see the correct time on the video in the Import window but after I submit the Import operation, the time shifts by 8 hrs (in my case I'm in PDT). Why would Adobe force us to accept this time shift without at least an option to disable it?

There's nothing fundamental that would prevent Adobe from fixing this problem in LR. In general, though, based on the past many years of experience, Adobe doesn't attach much priority to metadata issues, especially video metadata issues.

Hi John, Great explanation.
However since PSE/PRE handles metadata and date codes properly, Adobe should be able to do it in LR. How much different could the import logic be? Of course, that is unless I am missing something here.

Thanks for that explanation, John. I'd love to see Adobe implement a fix.

Details about the cause of this bug in LR:

The QuickTime spec "strongly recommends" that date/time values be stored as UTC (GMT):

https://developer.apple.com/library/m...

The iPhone (iOS 7) does indeed store a video's Media Create Date as UTC.

When LR reads the Media Create Date of a QuickTime video, it correctly interprets that date/time as being in UTC. But the problem arises with LR's policy for handling date/times with time zones. When displaying a metadata date/time containing a time zone to the user, LR always hides the time zone. So the QuickTime date/time will appear to the user as shifted into UTC.

The fix is straightforward: When LR reads a QuickTime date/time, it should convert it into the time zone of the computer running LR. While this would produce incorrect results for the uncommon case of videos taken in one time zone but imported to a computer in another time zone, in the common case this fix would produce the desired result. And this would be better than the current situation, in which the displayed date/time is almost always wrong (except for the minority of users who take videos in GMT while not in daylight savings time). (And shame on Apple for defining a spec for date/times that doesn't allow for time zones.)

An example makes this clearer:

1. I took an iPhone iOS 7 video at 2014:02:03 19:16:26 -8:00.

2. Exiftool shows Media Create Date is the UTC version of that: 2014:02:04 03:16:26.

3. When the video is imported into LR 5.3, LR correctly interprets that date/time as being in UTC -- the LR SDK call to photo:getRawMetadata ("dateTimeDigitizedISO8601") returns "2014-02-04T03:16:26Z". (Z is ISO8601 designator for UTC.)

4. As with all metadata date/times, when LR displays the date/time in Metadata panel, it drops the time zone, thus showing Capture Date/Time as "February 04, 2014 3:16:26 AM".

5. If in step 3, LR instead represented internally the QuickTime Media Create Date in the local time of the computer doing the import into LR ("2014:02:03 19:16:26-8:00"), then the Metadata panel would display the correct Capture Date/Time -- "February 03, 2014 7:16:26 PM".