P: iPhone video Capture Time is shifted upon Import

[tred56ut]

Beginning with at least the iPhone 4S, and continuing with the 5 and 5s, I see that videos shot with those devices show a capture time that seems to relate to GMT, when it was actually shot at GMT -5.

The videos show a correct creation time in Finder prior to import, but this odd shift occurs upon import. I know that the capture time can be edited in Lightroom, but I'd rather see the correct time on import.

This happens in Lightroom 5.3, but also occurred all the way back into 4.

[John R Ellis]

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

[tred56ut]

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

[Beany from Brooklyn]

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.

[John R Ellis]

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.

[Tea man]

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?

[John R Ellis]

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

[Tea man]

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.

[arbell15]

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.

[John R Ellis]

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.

[Rick Baumhauer]

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.

[Beany from Brooklyn]

John is a HUGE wealth of knowledge and asset to the community.

Here is what bothers me, PSE seems to work while LR does not for creation dates of movies. If tat is true then why?

[John R Ellis]

"PSE seems to work while LR does not for creation dates of movies. If tat is true then why?"

That's a good question.  I'll look into it.

[Rumboogy]

I am having the same problem with LR5.7.1 when importing MP4 from a Nexus 5 phone (Android 6.01.

[John R Ellis]

I just tried the PSE 14 Organizer with a couple of sample MP4s.  It appears to be using the file's date modified, not any metadata in the file.   That approach works much of the time, since the camera/phone will usually set the file's date modified to the camera's clock (cameras and phones that understand time zones will set it to local time).

The problem with using file date modified and file date created is that too many applications, utilities, and cloud services don't preserve them as the file is copied and moved.  Long-time Mac users have relied on the tradition of Mac apps preserving those dates, but these days there are many Mac apps and utilities that don't (including from Apple, and most especially including LR).

But using file date modified is often better than file date created, especially on Windows, where the convention on Windows is that the file date created represents when that specific copy of the file was created, not when the original was created.  (I.e. making a copy of a file sets the copy's date created to "now".)

The whole point of photo and video metadata is to preserve important information inside the file in a documented way that all applications respect. But with respect to capture date, the industry has collectively screwed it up.

[Beany from Brooklyn]

Thanks John. That makes sense to me.

[FeedbackCommunityMember]

Interestingly, LR mobile on the iPhone recognizes the correct timestamp when I import the video into LR mobile. Only LR CC on my mac shows an incorrect timestamp. Would be nice if LR mobile would sync the correct timestamp to LR CC on the Mac... (or LR CC on the Mac would have the same algorithm to evaluate the timestamp)

[FeedbackCommunityMember]

Please fix this already! Super annoying.

[tred56ut]

Hooray! Three years after I started this thread, someone on the Lightroom team has acknowledged it and said they're on it. I'll believe it when I see it, but I'm hopeful.

@LR_Tom: @five__19 Per your Lr time stamp bug. Yes, we do care, I’m tracking a bug filed against the shared component we use to parse date/times. (https://twitter.com/LR_Tom/status/806...)

[Victoria Bampton LR Queen]

That's not just someone. That's the boss. 🙂

[FeedbackCommunityMember]

Lol quite the timing to complain about this 😄

[FeedbackCommunityMember]

I've encountered the same issue with my new iPhone 7 but not with my Sony RX100 III as Rick has with his Sony RX100 II. My husbands Sony RX 100 does not show that problem either. When I spoke with the Apple help he could not reprouce the problem with his iPhone and LR either. Strange isn't it?

[John R Ellis]

The Sonys (as do most non-phone cameras) store the capture time as local time, whereas the iPhones store it as UTC (GMT).   This obviously confuses LR.  It's a consequence of a poorly designed QuickTime specification: https://feedback.photoshop.com/photoshop_family/topics/iphone_video_capture_time_is_shifted_upon_imp...

[FeedbackCommunityMember]

While we wait for a fix I have an imperfect workaround that works for me. I have a Sony a7Sii and I now set the "Area" (Timezone) to "London" and "Daylight saving" to "Off". This means that the time value never changes when Lr or the camera tries to calculate UTC time for Capture (Create) Time.

This is an inelegant solution because I now have to manually change the time when daylight savings comes on and off. But that is only twice a year.

Incidentally this also accounts for why some Sony users have this problem and others do not. If these values were never changed from UTC then the camera thinks it is in the UTC Timezone and they will never have this problem.

Moreover, the a7Sii does not have a GPS so it will never know what Timezone it is really in unless I tell it.

[Rikk Flohr: Photography]

Adobe released Lightroom 6.9/CC2015.9 today.

This issue should be corrected in this release. Please give it a try and let us know if you see any further issues. 

Complete information about this update can be found at the Lightroom Journal: http://blogs.adobe.com/lightroomjournal/2017/03/lightroom-cc-2015-9-now-available.html

If you don’t see the update in your Creative Cloud App, you can use the kbsc [Cmd/Ctrl]+[Opt/Alt]+[ R ]  to refresh your app. If you are a perpetual license holder, you can access the update via Help>Updates...

Refer to this for any installation issues: http://blogs.adobe.com/lightroomjournal/2013/06/keeping-lightroom-up-to-date.html#lrcc2015

[Tea man]

Will this fix only impact future imports of video or will it try to correct past videos already in the LR library? I have already corrected most of my videos (painfully) but not all. I'd hate for it to get confused and make a mess of the capture time unless it was able to do it somehow flawlessly and accurately.