Tracklogs and timezones

[ZimFromIRK]

This is reporting a bug in Lightroom classic 13.1 build 202312111226-41a94e8 on Windows 11.

I recently returned from a European river cruise and ran a tracker on my iPhone and Apple Watch to gather tracklogs for the trip. That worked out fine.  The program, Geotag Photos 2, created a GPX file and I verified that it matches the GPX schema, with latitude, longitude, and UTC timestamp for each logged point.

There are some serious problems in using this with Lightroom classic, however:

• The GPX tracklog contains timestamps in UTC, per the GPX XML schema. For most of Europe, that's an offset of +1 hour over UTC. However, when I load the tracklog for each day of my trip into Lightroom, it converts to local time: currently UTC-6 for my location in Texas.
  
  
• For example, in the map module, if I hover over a portion of the track near an already timestamped photo that shows 11:04AM, the tracklog reports 5:03AM (see attached image--off by 1 minute is ok). This is the UTC timestamp of the tracklog converted into my local time.
  
  
  • The tracklog GPX file contains a comment at the start of each track giving the timezone offset from UTC time in minutes. For this track it says +3600, which is UTC+1 and is correct. 
    
    Is this something that Lightroom is supposed to be able to process?There's nothing in the GPX schema to specify a timezone offset, which is unfortunate but I was wondering if this was some kind of extension.
    
    
• If I use the "Track Time Offset" function to add 6 hours to the time that's displayed when I hover over the tracklog (basically specifying local time where the photo was taken), it has no effect on the timestamps displayed when I hover.
  
  
  • See this screen capture.  The photo was timestamped by my camera at 11:04:26 (the actual time the photo was taken), while hovering over the tracklog where the photo was taken shows 5:03:23, which is the UTC time stored in the GPX file, adjusted to my local timezone.
    
    
  • The Lightroom BUG is that "Track Time Offset" has no effect over the timestamp displayed when I hover over the tracklog. 

I'm thinking that Lightroom really needs an option to not convert an imported GPX tracklog to local time, but to leave it in UTC time.  Having to apply TWO adjustments: back to UTC time, and then to the timezone where the tracklog was recorded is just too confusing for us mere mortals. It's as if Lightroom assumes you only collect tracklogs in your home timezone.

Also, Lightroom does not seem to save the entered tracklog offset anywhere.  When I reload the tracklog, everything is reset to local time again.  So I'm thinking the only way to reliably store a GPX tracklog for later use in LIghtroom is to convert the UTC times in the tracklog so it's relative to the local timezone -- then I could load it at will to see the track I took when I walked in each city.  However, this just seems wrong to me.

I uploaded a sample tracklog. I can't upload a GPX file so I added a .XML extension. Change it back to .GPX or Lightroom can't see it.

There is another annoying bug in GPX file handling, but I'll report that as a separate issue.

[John R Ellis · Accepted solution]

The Map module is working with tracklogs as Adobe designed it, though many people (including me) find the design extremely confusing.

(Some background: I filed the original bug reporting that the Tracklog Time Offset command wasn't documented in the Help, and then I had to correct mistakes in the original version of the Help. The tech writers gave up trying to fully document its confusing behavior:

https://helpx.adobe.com/lightroom-classic/help/maps-module.html#timezone_offset_auto_tag)

- Tracklog times (which are recorded in the GPX file in UTC) are always displayed on the map (when you hover) converted to the time zone of the computer running LR. The Tracklog Time Offset command doesn't affect this.

- Map always treats the capture times of photos as in the time zone of the computer running LR. Map (and the rest of LR) ignore any time zones that may have been recorded with the capture times in EXIF (it's only in the last few years that the EXIF standard allowed cameras to record time zones, and LR was never updated to take advantage of that).

- The Tracklog Time Offset is used only by the Auto-Tag command when mapping tracklog times to photo times. But it doesn't change the contents of the GPX file, and it's setting is lost when you load a new GPX file or restart LR.

Seven years ago, when Adobe introduced the full Lightroom Ecosytem (Cloud, Mobile, Desktop), they stated that they would focus their efforts in Lightroom Classic on Develop and image quality. They've stayed true to their word, so I think it's unlikely they would consider Ideas proposing improvements to the design of the Map module.

[ZimFromIRK]

Hi John: thanks for the great reply.  You've clarified so much. It's a shame that Adobe isn't interested in the map module because it's quite good -- just, as you said, really confusing. It would solve a lot of problems if Lightroom would just honor the time offset when hovering over the track as presuably that would be the time and location that's applied to any photos.

Since I'd like to archive my GPX tracklog for each travel day in the photos folder, and don't really want to deal with computing the offset every time I load it (although I guess I could put that offset in the filename), and also would like the hover times to be accurate, I guess I'll write a little conversion program to mangle the UTC times in the tracklog for my current timezone, taking the original timezone into account.  That should effectively trick Lightroom into processing the tracklog correctly -- at least until I move to a different timezone.  Or maybe until daylight savings time takes effect, when the stored times will be off by an hour again.  It really makes no sense to use the current timezone.

It seems like I struggle with the tracklogs every time and, as you said, there's no hope that Adobe will fix it.  So I'll find a workaround. 

Thanks again for taking the time to reply.