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.

[johnrellis]

The fix will affect imports of new videos and when you apply Metadata > Read Metadata From File to existing videos.   If you don't do Read Metadata From File on existing videos, their capture dates will remain unaffected.

[arbell15]

Couldn't wait to get home and try this out.  Upgraded and tried to sync the meta data of the folder and no change in the date of impacted iphone videos.  Delete one file from the library, reimported and still no change in the date.  Video was taken around 6:34 PM pacific time and shows 2:34 AM on lightroom 6.9 still.

Also just imported some recent photos/videos from my iphone to see if maybe there was some metadata/etc that was forcing the time and can confirm that this issue is not fixed, importing fresh videos from iphone or reimporting old videos still yields the incorect time for the videos (It's still GMT timezone).

[ethani48380925]

I also updated my version of LR and tested it with two new videos from my iPhone 6.  One I imported directly from the iPhone, the other I first copied to my hd, adjusted permissions and then imported.  Both continue to have the wrong time (8+ hours).  I don't seem to have the option to read (or save) metadata from the file for any videos.

[jamescodeglia]

Same here: same timezone issue persists using my iPhone 6s.

[johnrellis]

"and when you apply Metadata > Read Metadata From File to existing videos. "

I misspoke -- you can't invoke Metadata > Read Metadata From File to videos.

[johnrellis]

LR CC 2015.9 (OS X 10.12.3) still shows UTC rather than local time when I import from an iPhone 7 (10.1.1).  I tried importing using a USB cable and from a video copied to the hard disk (synced via Dropbox).

[simonsaith]

For people who still experiences the issue, could you share a short video clip online that demonstrate the problem. We'll investigate. Thanks.

[tred56ut]

I'm the original poster, from over three years ago (!), and I'm beyond disappointed to learn that despite claiming in the release notes for 2015.9 that this exact problem was fixed, IT IS NOT (macOS 10.12.1, iPhone 7, iOS 10.2.1).  I brought the video into Lightroom Desktop via a sync with LrM.  Of course, viewing the same video on my iPhone in LrM, the capture date is correct.  

The curious phrasing of the release note could be read to limit the fix to the iPhone 6-sourced videos, but I don't think that's what was intended, and at least one other post in this thread shows that the fix isn't a fix with an iPhone 6, either.  

This is maddening, Adobe.  Get your heads out of your arses.  

[tred56ut]

A video clip of what?  

The video that results in what's shown in my screen grab can be found here:  https://youtu.be/Z3ZG4E_XNj0.  

[simonsaith]

A short video clip of video shot with your iPhone, that when imported into Lr 6.9, still demonstrate the time zone issue. We will do some testing on our side but we want a few samples of your video that can reproduce the issue in Lr. We want to collect a few video samples from you to make sure there is nothing special about your videos.

Our QE have confirmed the bug fix using the sample videos that we have. It might be possible that we might have missed something. As you might not know, the MPEG4 standard only defines the capture time in UTC. But in the case of videos captured by iPhone, the time zone info is recorded in a separate proprietary location. Video metadata is always messy because there is no agreed standard and each vendor might decide to do things differently.

[johnrellis]

See this video from an iPhone 7 / iOS 10.1.1: https://dl.dropboxusercontent.com/u/21811200/2017-03-0818.23.46.mov . The original filename is 2017-03-08 18.23.46.mov, which is the local time of capture (2017-03-08 6:23:46 PM UTC+8).  Exiftool shows these two fields:

[QuickTime]     Create Date                     : 2017:03:09 02:23:46

[QuickTime]     Creation Date                   : 2017:03:08 18:23:46-08:00

The first field is the QuickTime-defined field containing the capture date in UTC. The second field is a non-standard field that Apple uses.)   LR imports the video with the capture time set to the UTC time, not local time:

[tred56ut]

Simon:  

Here's mine:  https://www.dropbox.com/sh/d8n428l3eeewbdh/AABAdCvNSlEFe2wts-OGCAqda?dl=0

I'll appreciate it if you commit to coming back to this thread to give us the results of your testing.  

I'd say that it is highly likely -- not merely possible -- that you guys missed something.  

Also, I am aware (from people like Mr. Ellis) that MPEG4 only defines the capture time in UTC, and that the time zone information for iOS videos is stored elsewhere, in a proprietary location.  You might not be aware that I don't care.  Look at the age of this thread.  Look at the absolute ubiquity of iPhones.  Look at the fact that the problem doesn't even exist in LrM!  Are you guys the market leader in this category, by leaps and bounds, or is Adobe a start-up?  Stop pointing fingers and fix this problem.  And the next time you think you've got it fixed, do a better job of making sure you're right.  

[ethani48380925]

Here's mine.  Recorded on my iPhone 6 on 3/8/17 at 12:18 AM local time (PST). 

Regarding Apple's proprietary location:  The fact that the field is accessible via Exiftool (as it is with my file as well) indicates that Adobe should be able to access this info as well.   Like Peter said, we aren't dealing with some obscure camera, here!

Also, I just checked footage that I shot in a different time zone (Israel UTC +3), and the Creation Date is accurate.  So, it seems to me that the whole "dilemma" mentioned earlier about determining local time is really a red herring, in this case.

[arbell15]

Do you all have what you need or are more needed?

[simonsaith]

The issue is confirmed and our QE is now in the process of verifying the new fix. Thanks all and apologize for the mishaps.

On the slowness in making progress on the original issue: In general, when metadata are stored in a proprietary location and in a proprietary format, companys like Adobe needs to get legal clearance from the vendor to parse such data. It is a known slow process. The technical detail is usually the easy part.

[tred56ut]

Simon,

Thanks for the update.  What's the timeframe for the actual fix?

Are you blaming Adobe's delay of over three years (read up on this thread to my original post) on legal issues?  Seriously?  If that's what you mean, I call BS.  But maybe you mean something else.  

Do you mean that the reason this so-called fix is actually no fix at all is due to legal considerations?  I don't think so.  

In any event, here's some advice:  The next time you are asked, or decide, to acknowledge that your employer has screwed up royally, leave it at that.  Don't go on to vaguely blame the need for "legal clearance."  That just is not the reason for this comically bad effort on Adobe's part.  

Finally, when acknowledging that your so-called fix isn't a fix at all, I wouldn't recommend finishing the same post by saying, "The technical detail is usually the easy part."  It clearly is not.  

[arbell15]

Peter, calm down.  They are on it and fixing it.  Please don't make them change their mind and ruin it for the rest of us.

Simon and Tom, I appreciate your dedication to making your product better, keep up the good work!

[tred56ut]

Thanks for being the voice of reason, Andrew.  

If some very fair criticism causes them to "change their mind and ruin it for the rest of us," then things are far worse than they even seem.  

[Tea man]

I find it surprising that this "fix" wasn't tested with actual video from an iPhone. I'm not aware of any iPhone owner who has not run into this problem in LRm, which begs the question do none of the developers at Adobe have an iPhone which they can take their own video and try it out? I strongly applaud Adobe for now finally trying to address this issue, but seriously, how could a release that "fixes" fthe problem be released and not tried on sample videos?

[Rikk Flohr: Photography]

This issue should be fixed in Lightroom CC2015.10/6.10.  Please update your system and let us know if you have any additional issues. 

Additional information on this update can be found here: http://blogs.adobe.com/lightroomjournal/2017/04/lightroom-cc-2015-10-now-available.html

[jamescodeglia]

Seems to be working for me with my iPhone 6s! Thanks, Rikk!

[arbell15]

Iphone7 here and the fix still doesn't seem to be working.

I've got a video that shows this in it's metadat:
Create Date 2017:03:26 23:50:09
Creation Date 2017:03:26 16:50:09-07:00

and after updating lightroom to the latest version, delete the file from the library and reimporting, the time in lightroom for it is still 3/26/2017 11:50:09 PM when it was taking at 4:50 in the afternoon PDT (UTC-7).

[Smit K]

Hi Andrew,

Could you share a sample video and screenshot of your metadata panel for the same video to keniya@adobe.com?

Thanks,
Smit Keniya
Adobe Lightroom Team

[arbell15]

Done.

[Smit K]

Hi Andrew,

Please find below the date and time shown in Metadata Panel for the video you shared in Lightroom 6.10/CC 2015.10



I do not see any issue. Could you confirm the same?

Thanks,
Smit