Lightroom: iPhone video Capture Time is shifted upon Import

  • 27
  • Problem
  • Updated 2 years ago
  • Solved
  • (Edited)
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.
Photo of Peter Preston

Peter Preston

  • 10 Posts
  • 3 Reply Likes
  • frustrated

Posted 6 years ago

  • 27
Photo of John R. Ellis

John R. Ellis, Champion

  • 4571 Posts
  • 1224 Reply Likes
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".
Photo of Neville Jones

Neville Jones

  • 1 Post
  • 0 Reply Likes
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.
Photo of Peter Preston

Peter Preston

  • 10 Posts
  • 3 Reply Likes
Thanks for that explanation, John. I'd love to see Adobe implement a fix.
Photo of Daniel Arbeeny

Daniel Arbeeny

  • 46 Posts
  • 0 Reply Likes
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.
Photo of John R. Ellis

John R. Ellis, Champion

  • 4571 Posts
  • 1224 Reply Likes
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.
Photo of Teaman

Teaman

  • 6 Posts
  • 1 Reply Like
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?
Photo of John R. Ellis

John R. Ellis, Champion

  • 4571 Posts
  • 1224 Reply Likes
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. :-<
Photo of Teaman

Teaman

  • 6 Posts
  • 1 Reply Like
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.
Photo of andrewrbell

andrewrbell

  • 18 Posts
  • 4 Reply Likes
This reply was created from a merged topic originally titled Iphone videos date/time incorrect in lighroom metadata.

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.
Photo of John R. Ellis

John R. Ellis, Champion

  • 4571 Posts
  • 1224 Reply Likes
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.
Photo of Rick Baumhauer

Rick Baumhauer

  • 49 Posts
  • 26 Reply Likes
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.
Photo of Daniel Arbeeny

Daniel Arbeeny

  • 46 Posts
  • 0 Reply Likes

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?


Photo of John R. Ellis

John R. Ellis, Champion

  • 4562 Posts
  • 1221 Reply Likes
"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.
Photo of John R. Ellis

John R. Ellis, Champion

  • 4562 Posts
  • 1221 Reply Likes
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.
Photo of Daniel Arbeeny

Daniel Arbeeny

  • 46 Posts
  • 0 Reply Likes
Thanks John. That makes sense to me.
Photo of Anthony Waitz

Anthony Waitz

  • 4 Posts
  • 0 Reply Likes
I am having the same problem with LR5.7.1 when importing MP4 from a Nexus 5 phone (Android 6.01.
Photo of Christian Hodel

Christian Hodel

  • 2 Posts
  • 0 Reply Likes
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)
Photo of Andre Richter

Andre Richter

  • 2 Posts
  • 0 Reply Likes
Please fix this already! Super annoying.
Photo of Peter Preston

Peter Preston

  • 10 Posts
  • 3 Reply Likes
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...)
Photo of Victoria Bampton - Lightroom Queen

Victoria Bampton - Lightroom Queen, Champion

  • 4973 Posts
  • 1934 Reply Likes
That's not just someone. That's the boss. :)
Photo of Andre Richter

Andre Richter

  • 2 Posts
  • 0 Reply Likes
Lol quite the timing to complain about this :D
Photo of Helene Gisin

Helene Gisin

  • 1 Post
  • 0 Reply Likes
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?
Photo of John R. Ellis

John R. Ellis, Champion

  • 4571 Posts
  • 1224 Reply Likes
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...
(Edited)
Photo of Rikk Flohr

Rikk Flohr, Official Rep

  • 5882 Posts
  • 1290 Reply Likes
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
(Edited)
Photo of Teaman

Teaman

  • 6 Posts
  • 1 Reply Like
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.
Photo of John R. Ellis

John R. Ellis, Champion

  • 4571 Posts
  • 1224 Reply Likes
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.
Photo of andrewrbell

andrewrbell

  • 18 Posts
  • 4 Reply Likes
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).
(Edited)
Photo of Ethan Isenberg

Ethan Isenberg

  • 28 Posts
  • 2 Reply Likes
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.
Photo of John R. Ellis

John R. Ellis, Champion

  • 4571 Posts
  • 1224 Reply Likes
"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.
Photo of andrewrbell

andrewrbell

  • 18 Posts
  • 4 Reply Likes
Do you all have what you need or are more needed?
Photo of James Codeglia

James Codeglia

  • 16 Posts
  • 0 Reply Likes
Same here: same timezone issue persists using my iPhone 6s.
Photo of John R. Ellis

John R. Ellis, Champion

  • 4571 Posts
  • 1224 Reply Likes
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).
Photo of Simon Chen

Simon Chen, Principal Computer Scientist

  • 1628 Posts
  • 542 Reply Likes
For people who still experiences the issue, could you share a short video clip online that demonstrate the problem. We'll investigate. Thanks.
Photo of Peter Preston

Peter Preston

  • 10 Posts
  • 3 Reply Likes
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.  
Photo of Simon Chen

Simon Chen, Principal Computer Scientist

  • 1628 Posts
  • 542 Reply Likes
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.
(Edited)
Photo of John R. Ellis

John R. Ellis, Champion

  • 4571 Posts
  • 1224 Reply Likes
See this video from an iPhone 7 / iOS 10.1.1: https://dl.dropboxusercontent.com/u/21811200/2017-03-08%2018.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:


Photo of Peter Preston

Peter Preston

  • 10 Posts
  • 3 Reply Likes
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.  
Photo of Ethan Isenberg

Ethan Isenberg

  • 28 Posts
  • 2 Reply Likes
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.
Photo of Simon Chen

Simon Chen, Principal Computer Scientist

  • 1628 Posts
  • 542 Reply Likes
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.
(Edited)
Photo of Peter Preston

Peter Preston

  • 10 Posts
  • 3 Reply Likes
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.  
Photo of andrewrbell

andrewrbell

  • 18 Posts
  • 4 Reply Likes
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!
(Edited)
Photo of Peter Preston

Peter Preston

  • 10 Posts
  • 3 Reply Likes
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.  
Photo of Peter Preston

Peter Preston

  • 10 Posts
  • 3 Reply Likes
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.  
Photo of Teaman

Teaman

  • 6 Posts
  • 1 Reply Like
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?
(Edited)
Photo of Rikk Flohr

Rikk Flohr, Official Rep

  • 5882 Posts
  • 1290 Reply Likes
Official Response
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
Photo of Peter Preston

Peter Preston

  • 10 Posts
  • 3 Reply Likes
It's true that "[t]his issue should be fixed in Lightroom CC2015.10/6.10."  It's also true that it should have been fixed in many preceding releases.  Unfortunately, the reality is it is not fixed, and that this seems to be beyond Adobe's ability to fix.  

Refer to the video here:  https://www.dropbox.com/s/5j4z96g8u61bqqc/IMG_6401.MOV?dl=0

I took that on my iPhone 7 (10.3.1) on May 8, 2017 at 7:59 PM CDT.  I imported it to Lr Desktop 2015.10 (macOS 10.12.14) via Lr Mobile on the same iPhone.  LrD shows a capture date of five hours after the actual capture date.  See the screenshot.  

Other videos taken recently and imported in the same manner show the correct capture date in LrD.  The only thing more maddening than a known bug that is ignored for years like this one, but which can be manually fixed, is a known bug that is reportedly fixed (twice!), and which sometimes seems to have actually been fixed, but not always!  

I'd prefer to hear that I'm crazy, or that I've missed something obvious.  I'd prefer that to the alternative, which is that Adobe is still stepping all over it's d*ck trying to fix this.  
Photo of Rikk Flohr

Rikk Flohr, Official Rep

  • 5882 Posts
  • 1290 Reply Likes
At the top of this page, you can see that the status was changed to In Progress. The bug is still open and additional fixes are pending. 
Photo of Peter Preston

Peter Preston

  • 10 Posts
  • 3 Reply Likes
I think you must have hit Submit prematurely, because surely you meant to add:

"...Adobe sincerely apologizes for issuing two separate releases in which we announced the bug was resolved, but in fact it was not. We know that the last release has made matters worse, not better. We also know that our paying users look to us to make their workflows easier, not harder. We are embarrassed by this clown-like series of errors, and we will soon post instructions by which our users, who we have been treating like unsuspecting beta users, may apply for refunds."
Photo of James Codeglia

James Codeglia

  • 16 Posts
  • 0 Reply Likes
Seems to be working for me with my iPhone 6s! Thanks, Rikk!
(Edited)
Photo of andrewrbell

andrewrbell

  • 18 Posts
  • 4 Reply Likes
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).
Photo of Smit Keniya

Smit Keniya, Employee

  • 223 Posts
  • 99 Reply Likes
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
Photo of andrewrbell

andrewrbell

  • 18 Posts
  • 4 Reply Likes
Done.
Photo of Smit Keniya

Smit Keniya, Employee

  • 223 Posts
  • 99 Reply Likes
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
Photo of andrewrbell

andrewrbell

  • 18 Posts
  • 4 Reply Likes
I see it different in my library.  I think maybe this is becasue I had imported this video with the old version?  I thought if I deleted it and reimported it it should pick up the correct date, but it looks like the metadata is staying?  how can I flush the old metadata after I delete it before reimporting it?

Photo of andrewrbell

andrewrbell

  • 18 Posts
  • 4 Reply Likes
I deleted the file and re imported it again and this time it was correct.  The change seems to work sometimes and not other times, i had 2 back to back videos, imported them, one had correct pacific time, other had GMT time.  I sent both of those videos to you.  in that case, i've tried deleting/reimporting the one in GMT and it won't fix itself.

I've also noticed when I import in the folder for these videos, if I hover immediately over a video during import it shows GMT time, and then if I come back 30 seconds later for some of the videos and hover over them, i has correct pacific time, but other vidoes never change.  I think I quickly imported the video above earlier today and imported it while the app thought the time was GMT.  The second time, I waited and imported after it showed pacific time.

There are several nasty bugs in this fix.
Photo of Rick Baumhauer

Rick Baumhauer

  • 49 Posts
  • 26 Reply Likes
I shot a few videos on my iPhone 7+ yesterday, and importing into LR CC 2015.10 mostly worked as it should. Unfortunately, it was only "mostly" - of the eight videos, six came in with the correct timestamps, but two came in off (late) by 4 hours. All were shot with the same settings on the phone.

When I export the original files from Photos, they show the incorrect file creation time in Finder (shifted four hours later than local EDT). The files that imported with the correct time in Lightroom also show the incorrect creation time in Finder (so no difference with the files that show the incorrect time in Lightroom), and all files show the correct time in Photos.

Links to the two files with the incorrect time in LR follow:

https://drive.google.com/a/baumhauerphoto.com/uc?id=0B1l4li0Nl6WGY25NamIzV25HRjQ&export=download

https://drive.google.com/a/baumhauerphoto.com/uc?id=0B1l4li0Nl6WGYnRHZl8tVEdScm8&export=download
Photo of John R. Ellis

John R. Ellis, Champion

  • 4571 Posts
  • 1224 Reply Likes
When I import those samples, LR is correctly reading the capture time recorded in the files:


For IMG_2120.MOV, ExifTool shows the following:
[QuickTime]     Create Date     : 2017:04:19 17:54:06
[QuickTime]     Creation Date   : 2017:04:19 13:54:06-04:00
The first line is the industry-standard QuickTime field recording the date/time in UTC, and the second line is the Apple proprietary field recording it in local time along with a time zone.

What capture times show up for those files in your catalog?  A screenshot of the Metadata panel would be great.
Photo of John R. Ellis

John R. Ellis, Champion

  • 4571 Posts
  • 1224 Reply Likes
"When I export the original files from Photos, they show the incorrect file creation time in Finder (shifted four hours later than local EDT)."

Not many Mac apps maintain the original file creation times these days.  Photos and iPhotos don't, and neither does LR.
Photo of Rick Baumhauer

Rick Baumhauer

  • 49 Posts
  • 26 Reply Likes
John - understood, I just wanted to point out that there was no difference in the data between files that imported with the correct time vs. incorrect time.

Unfortunately, I already changed the time in LR (which doesn't reference the original file, but a copy that is imported directly from my Photos library). I tried deleting those two files and reimporting, but now they come in with the correct time.

It appears that those two files originally imported with the UTC data for some reason - I have LR rename the files on import, and the time is part of my filename. Those two files were named (and sorted) based on the UTC time, not local. I imported all eight videos at the same time, and those two were the only ones that came in with incorrect time (just can't recreate it, unfortunately). If it happens again, I'll leave the copies in LR alone for further testing.
Photo of John R. Ellis

John R. Ellis, Champion

  • 4571 Posts
  • 1224 Reply Likes
If it's an intermittent bug, that will be much harder to track down. Is there any possibility those two files were imported by a previous version of LR?
Photo of Rick Baumhauer

Rick Baumhauer

  • 49 Posts
  • 26 Reply Likes
No - all of the videos were shot yesterday, all imported at the same time into LR 2015.10.
Photo of Mark L

Mark L

  • 36 Posts
  • 2 Reply Likes
I am having the same issues as Rick Baumhauer - *some* of the iPhone videos have imported with the correct time, while others have not.  We are now in a way worse situation than before, when the functionality was broken, but at least I could fix it with a batch change.  Now, I have to go through each of hundred of videos and run ExifTool to check whether LR messed it up or not.  Good grief - please can we get a proper fix for this ASAP.  This is costing me huge amounts of time, and just adds volumes to the distrust of the metadata in LR.  
Photo of John R. Ellis

John R. Ellis, Champion

  • 4571 Posts
  • 1224 Reply Likes
"*some* of the iPhone videos have imported with the correct time, while others have not."

If you upload a problem video to Dropbox or similar and post the sharing link here, we might be able to track down the problem. Without a reproducible test case, Adobe is very unlikely to address the issue.
Photo of Mark L

Mark L

  • 36 Posts
  • 2 Reply Likes
John - Will try find some examples where I see this happening repeatedly.
Photo of Mark L

Mark L

  • 36 Posts
  • 2 Reply Likes
I have been trying and while this defect has clearly not been fixed, it does not occur with the same set of files on each import.  That *is* the defect.  LR randomly imports some correctly, and some incorrectly.  I am not the only one having this issue, so it can't be just my environment.  This is really such a basic function that I shouldn't even have to think about it.  I can reliably and repeatedly extract the correct datetimestamp from all of the MOV files on my iPhone with a simple ExifTool command.  How is LR struggling so badly with this?  So basically I have zero trust in LR metadata for videos from an iPhone, and have to manage it all manually.  Also, LR fails pretty miserably on importing GPS data from iPhone MOV files, although this is reproducible and I will raise a separate defect and attach example files - again this data is easily and reliably extracted with a simple ExifTool command for me.  And finally, many LivePhotos (but not all) imported from iPhone show up as green blobs in LR.  Also reproducible and will raise another defect on this.  This all seems pretty crazy for what is supposed to be top-notch software.  Seems like one of the most used video cameras on the planet is really not tested very much.
Photo of Mark L

Mark L

  • 36 Posts
  • 2 Reply Likes
Okay so I've tested this out repeatedly now, and I don't think there is anything special about my iPhone (7 Plus), so can't see why this is so difficult to do.  All LR needs to do is to use the "QuickTime:CreationDate" tag in .MOV files from an iPhone.  It took me all of 5 minutes to write an ExifTool command that copies this value to the QuickTime:CreateDate and QuickTime:ModifyDate tags before I import into LR, and this works 100% perfectly so far, every time I have run an import - no more random LR ridiculousness.  The command I ran is: 

exiftool -overwrite_original "-quicktime:createdate<quicktime:creationdate" "-quicktime:modifydate<quicktime:creationdate” FILE/DIR

I really like LR and I really want to continue using it, but seriously some attention needs to be paid to the video handling.  How can Premiere handle video so effortlessly and yet LR be so horrible at it.  Do these teams hate each other and refuse to share or something?