Misdirection For Using GPS Tracklogs And Lightroom’s Time Zone Offset Feature…
by George on November 14, 2012
GPS: 46°2’42″ N 9°21’23″ E
Photographs © George A. Jardine
Getting comfortable using GPS when I travel and shoot has been creeping up on me for several years now. It is a slightly peculiar beast, and putting your finger on the exact purpose GPS serves in photography can be a bit tricky. Combine that with the somewhat obscure nature of how timestamps work, and you’ve got a subject you can sink your teeth into. (And just as quickly, you can get it wrong. Which unfortunately, is what I found today in a tutorial on the esteemed AdobeTV.)
Ever since the early versions of Lightroom, we’ve had an innovative feature that linked GPS metadata to Google Maps, and it was that feature that first prompted me to purchase a GPS unit and start working with it. But you still had to encode your images with GPS metadata before you could do anything with it. At the time, geocoding photos was not nearly as easy as it is today. Looking around for a little help, one of the engineers on the Lightroom team recommended that I try a program from Houdah Software, and that got me moving in the right direction. (HoudahGeo is still my favorite way to pull .gpx tracklogs from my Garmin GPS unit, which surprisingly, Lightroom does not yet do.)
GPS: 39°41’49″ N 104°58’9″ W
Early Frost
With Lightroom 4 we now have the Map module, which adds its own special twist to the mix. The Map module lets you drag photos directly onto the map, embed GPS metadata, reverse geocode location information, filter and select photos within any visible map area, and all sorts of other cool tricks. And in general, they’ve made it all pretty easy to use.
But there is one, small fly in the ointment. When I first started sniffing down this path, I was having a bit of trouble figuring out how to use Lightroom’s Time Zone Offset feature. And it goes back to that timestamp thing. The heart of the problem is that a timestamp is just a timestamp, and can only tell you what time a photo was shot, in some local time. Most cameras do not store the time zone that it was in at the moment of exposure. And if they do, it’s stored in a proprietary metadata tag that is not readable by most software. So the timestamp is completely ambiguous.
From what I understand, this incredibly inelegant situation is not the fault of Adobe software engineers, or of Japanese camera manufacturers, or anyone else you might think to point your finger at. But rather, timestamps are what they are because the EXIF specification simply does not allow for a local time zone entry!
GPS: 33°49’32″ N 116°32’49″ W
Are you kidding me?
Some cameras do allow you to set a time zone on the menus, but really that’s just a red herring. There is still no context recorded in camera metadata to give the timestamp meaning. (Nothing in EXIF, anyway, that is used by Lightroom. See Manfred’s comment below.)
GPS units take a slightly different tact on the problem. They ignore the crucial idea of context too, but they do that because they can. GPS units simply record all timestamps as if they were in one time zone that never changes: UTC. (UTC = Coordinated Universal Time. Same as GMT or Zulu time, whatever you want to call it.) Sure, it’s true that you can set a time zone on your GPS unit, but that’s just so that you can read a local time on the GPS display that makes sense. This time zone setting has absolutely nothing to do with how the GPS understands where you are, or how it records that position into the tracklog. It simply records everything in UTC. Which makes sense. After all, it is a global system.
GPS: 42°56’45″ N 122°10’9″ W
Crater Lake, OR
Given all of that, the problem should be coming into a bit better focus now. In order to match up the timestamps created by your camera to the timestamps recorded by your GPS unit, your computer needs more information. It needs to know what the timestamps in your photos mean, or… put another way, it needs to have the context that comes from the time zone.
HoudahGeo has a very straight forward way of obtaining that bit of info. The moment you try to load any photos into it for geocoding, it pops up a small dialog and simply asks for it. It also provides a starting point (an assumption), by looking at your computer clock, and pulling the local time zone from there. And it puts the assumption right in front of you for your approval. The text in the dialog says “Camera time zone:”, and there’s a pop-up menu, conveniently set to your local zone. Or whatever time zone your computer is currently set to.
GPS: 36°53’7″ N 104°25’59″ W
Not My Motorcycle!
So it’s unmistakable. HoudahGeo is asking you to verify the time zone of the photos you’re loading, the moment you try to do anything with it. There’s no escaping it. If you’re sitting in your hotel room in China, and you’ve been diligent enough to set your computer clock to the local time zone, (and… you’ve set your camera’s clock to the correct local time, before you started shooting) then geocoding is a slam dunk. You just load the photos, then load up the .gpx tracklog from your GPS device, and HoudahGeo matches them up for you, calculating the offset from the unit’s GMT-based timestamps to your photo’s ambiguous EXIF timestamps.
But then we come to Lightroom. Once you’re in the Map module and you’ve loaded up your tracklog, if you’re still in the same time zone that the photos’ timestamps are in, Lightroom’s Auto-Tag feature will work perfectly for you. My trouble with it is that there’s not a hint anywhere that Lightroom is making the same assumption as HoudahGeo, but that’s exactly what it does.
Now, I agree that the software has to start somewhere. But there are two major problems here. First, Lightroom doesn’t give you a clue that it’s making an assumption about the time zone, or that you might need to match these two things up. (Especially for beginners, that’s a problem. HoudahGeo asks you to verify the camera time zone every time you use it.) Second is that, in general, when I’m traveling and shooting, I don’t want to be thinking about GPS metadata and time zones. I want to think about those things once I’m back home.
After doing a bit of thinking on the subject of timestamps, and after polling dozens of my friends and customers who regularly shoot with GPS, I found that I was not the only one. Most photographer’s would rather worry about this stuff when they get home. Which means that Lightroom’s assumption about where to get a useful time zone will nearly always be wrong.
This means that if you want Lightroom to auto-tag your photos to a tracklog, you’re going to have to tell Lightroom where the photos were taken relative to the computer’s current time zone. Thus, the Time Zone Offset feature, which is not exactly self-explanatory. (Also confirmed by my poll.)
Now, I’m not writing this to point fingers at the UI designer or the engineers. There are lots of other aspects of Lightroom that will ensure my job security as an educator. But I’m writing it because just this morning I watched one too many video tutorials that got it so utterly wrong, I couldn’t stop myself.
GPS: 38°48’51″ N 115°17’46″ W
Desert Love
This feature is not that complicated, and it deserves to be understood because it’s incredibly useful. It’s just been hindered by a really bad user interface, and further obscured by tutorial jockeys who won’t take the time to do a little research. The easy way to think about it is that you have to tell Lightroom how many hours apart the time zone of the photos is (or was), from the time zone your computer clock is currently set to, before auto-tagging will work. And rather than show you a step-by-step here on the blog, I’ve taken 6 minutes out of tutorial #7 from my Catalog Management series, that shows you exactly how to do it.
It’s a free video, and you can watch it by clicking here.
Previous post: Does Library Folder Organization Matter?
Next post: 5 New Denver Lightroom Workshops at CPAC…
{ 16 comments… read them below or add one }
A timely intervention George. Well explained. Does this mean that we have to wait for camera manufacturers to start adding in time zone info before this all becomes easy.
Brian
Thanks, Brian.
Don’t hold your breath for camera manufacturers to “add in time zone info”. There’s no place in EXIF for time zones! Still researching “built-in” GPS units, and I’ll update in a few weeks.
George
Excellent background on a complicated subject – as usual, you explain it all so well.
Hi,
I use a Canon 5D MkIII where I can set the timezone in the camera.
I just dumped the metadata of a 5DIII image with exiftool. This dump contains these lines:
TimeZone : +02:00 TimeZoneCity : Paris
For me this means: in principle LR could automatically set the correct time. All necessary information is there…
Manfred
True that the newer Canon and Nikons have a menu item for Time Zone. But there is no place for it in EXIF, and LR does not use it when calculating the “assumed” time zone the photos were taken in. As of 4.3, LR simply uses the computer time zone.
Where is the new Canon metadata for time zone stored? What field?
It would be great if the LR team would update the way the offset is calculated for newer cameras that have this metadata, but I wouldn’t expect to see it coming any time before 5.0.
Also, it’s actually slightly more complicated than that, because of DST. This is from C. Newman’s “Date and Time on the Internet” draft of 1997……
4.1. Coordinated Universal Time (UTC)
Because the daylight rules for local timezones are so convoluted and can change based on local law at unpredictable times, true interoperability is best achieved by using Coordinated Universal Time (UTC).
– - – - – - – - –
It is for this reason (and because GPS units only record UTC) that I always leave my camera set to UTC, and correct timestamps once I’m home editing. Further, I include the local time zone abbreviation and offset in keywords, so that there will never be any ambiguity later, when (not if…) some local government decides to change their DST rules.
mulita.com/blog/?p=2746
George
Second update for Manfred. Just received my Canon GP-E2 for the 5DMKIII. The good news is that simply putting a battery into it, turning it on and taking photos, works perfectly. Despite the fact that my camera clock and time zone are set to GMT! (I’m in Denver, CO) Which confirms that no offset is required when a dedicated unit puts the GPS coordinates directly into file metadata, and that the time zone is simply not taken into consideration, at least with LR. At that point, the timestamp and the GPS coordinates are completely independent of each other, and no correlation is needed.
Next test is to try it using the log feature, convert the track to .gpx, and see what it contains.
G.
I will be taking a family vacation to Italy in 2013 so your location workflow dvd was a god send! I am considering purchasing an external GPS unit for my Nikon D7000 and am looking forward to your update on GPS when you get a chance to try your Canon GP-E2. Do the external units automatically give us a track in the map module? Bob
Bob, I’ve been working with the GP-E2, and it is spectacular. It’s truly plug-and-play, when it comes to embedding GPS metadata as you shoot. But no, it does not automatically give you a track in the Map module. Getting the tracks into Lightroom is a bit more work, but worth it if you need to tag photos taken with a second camera or something. But in the end, if you’re only shooting with a camera attached directly to the unit, you never really need the tracklog.
George
I, too, was trapped during a recent vacation in Japan. I adjust my phone=GPS-tracking device plus my camera to the time zone I am in, but not my laptop – I would consider this very weird. LR does a poor job of this auto-assumption according to computer time zone. Jeffrey Friedl shows how it should be done in his Geoencoding plug-in: just asks in what time zone the photos should be interpreted in! Answer for Japan is UTC+9 hours, and everything is correct. Whereas in LR’s map module I had to take into account that my laptop had changed from summer time to MEZ again in the middle of my vacation…
The major reason Lightroom fails is that LR does not deal with timezone properly. It would pretty easy to implement. When downloading images from your camera, LR should ask (and remember) what timezone you have set your camera too. And you never touch it in the camera. I choose to do UTC so I never have to deal with either daylight saving or timezone – also because that’s what GPS uses. From there, you have a reference time that can be mapped on the GPS tracklog. Bonus point it would also be possible, with that to determine the timezone of the photo to display the time for it as it was on location.
FWIW, the Maps feature in Aperture 3 deal with it properly – beside a few quirks / bugs – is it ask camera and actual timezone, etc.
This is incorrect. The point is not that Lightroom “does not deal with timezone properly”. Lightroom does not look to metadata for a time zone because there is no place in EXIF for a time zone. Additionally, many cameras still don’t have a time zone setting! Those that do, store it in a private maker note, in the absence of a formalized place for it in EXIF.
George
Thanks for the concise explanation and video. I was having trouble wrapping my head around this one, but now I understand it.
As an addendum, Even if you do set the time zone offset correctly in LR when you hover your mouse over a displayed track in the Map Module display, the pop up that shows you the date/time for that track point is showing you the date/time based on your operating system time zone, not on the time zone where you were when you recorded the track-log. So if my computer is set to Pacific time, and I recorded a GPX track-log in Boston, and was at some location, say at 9:00 am, LR tells me I was there at 6:00 am. This is very misleading.
Dan
Dan, this is true. But the trick is to set your system clock to the time zone the track log was recorded in…. after you load the track log.
Sad that there are so many bugs in the code here… but the side benefit of doing it this way is that you then don’t need to futz with an offset.
Hope that helps, George
Thanks for the response. I figured out that work around but it a poor excuse for a solution. However, it is a pain to constantly keep changing my system clock – which then mucks up my reminders in Outlook, back up schedules and most anything that depends on the clock. In addition in one LR session I may need to deal with images for several trips in several very different time zones. So, I guess the work around is better than nothing, but not much. I posted it as a bug report on the Adobe site and maybe adobe will see fit to address the issue with a fix rather than a work around. Thanks for responding. — Dan
Once again, Dan, I agree. The way the track offset works was the subject of much controversy from the beginning (basically, it sucks), and it has many bugs that have never been fixed.
As a permanent workflow solution for my travel I got in the habit of photographing a GPS clock on the end of every card, because each of my cameras drifts at a different rate. I keep them all set to GMT, and then adjust for the drift on a card-by-card basis with a script that sets new timestamps for all photos on the card based on the exact offset calculated with the shot of the clock. Then all I have to do is be sure my computer clock is set to GMT when I auto tag the images to the GPS track.
It’s work, but it makes it perfect…. down to the second, no matter how many cameras I’m shooting with.
George