Skip to main content
T
thomas5CED
Inspiring
April 8, 2026
Question

Timezone offset not handled correctly

  • April 8, 2026
  • 2 replies
  • 62 views

I have two photos taken with two cameras only a few seconds apart. But the timezone of the cameras differ. This is correctly reflected in EXIF, but Lightroom fails to recognize this.

The FIRST photo has the following relevant exif tags (as per exiftool -H -n):

0x9003 Date/Time Original              : 2026:03:29 16:52:55
0x9004 Create Date                     : 2026:03:29 16:52:55
0x9010 Offset Time                     : +01:00
0x9011 Offset Time Original            : +01:00
0x9012 Offset Time Digitized           : +01:00

and Lightroom Classic’s getRawMetadata returns

dateTime = "796488775"
dateTimeDigitized = "796488775"
dateTimeDigitizedISO8601 = "2026-03-29T16:52:55+01:00"
dateTimeISO8601 = "2026-03-29T16:52:55+01:00"
dateTimeOriginal = "796488775"
dateTimeOriginalISO8601 = "2026-03-29T16:52:55.000+01:00"

 

now the SECOND photo has:

0x9003 Date/Time Original              : 2026:03:29 11:52:09
0x9004 Create Date                     : 2026:03:29 11:52:09
0x9010 Offset Time                     : -04:00
0x9011 Offset Time Original            : -04:00
0x9012 Offset Time Digitized           : -04:00

and

dateTime = "796470729.685"
dateTimeDigitized = "796470729.685"
dateTimeDigitizedISO8601 = "2026-03-29T11:52:09.684722-04:00"
dateTimeISO8601 = "2026-03-29T11:52:09.684722-04:00"
dateTimeOriginal = "796470729.685"
dateTimeOriginalISO8601 = "2026-03-29T11:52:09.684722-04:00"

 

Remarkably ALL timestamps are wrong:

from datetime import *
from zoneinfo import *

epoch = datetime(2001,1,1,tzinfo=ZoneInfo('GMT'))

str(epoch + timedelta(seconds=796488775))
# '2026-03-29 14:52:55+00:00'
str(epoch + timedelta(seconds=796470729))
# '2026-03-29 09:52:09+00:00'

The first photo timestamp is offset by 1 hour (this is 14:52+0 is 15:52+1) the second timestamp is wrong by 6 hours (9:52+0 is 5:52-4). Interestingly, their difference matches the difference in the two timezones.

 

This causes user visible problems beyond the Lua API: Both photos, even though taken seconds apart are sorted in library view according to their timestamps, to they are 5h apart when sorting by capture time and not next to each other.

    2 replies

    johnrellis
    johnrellis
    Legend
    April 8, 2026

    LR ignores any time zone recorded in EXIF:OffsetTimeOriginal, paying attention only to the contents of EXIF:DateTimeOriginal. In the SDK, the value of photo:getRawMetadata (“dateTimeOriginal”) will be a Cocoa timestamp interpreting EXIF:DateTimeOriginal in the time zone of the computer running LR.

     

    When LR 1 was released in 2007, the EXIF standard had no notion of time zone for date/times, so LR treated all capture times as “local”.  EXIF 2.31 finally added the notion of time zone to the standard in 2016, 9 years later, and Adobe has never changed the design of LR to treat capture dates as specific to a time zone. 

     

    That would be a non-trivial change, since many cameras that aren’t connected to the Internet still don’t have a notion of time zone and don’t record time zone in EXIF. I very much doubt Adobe would ever take it on.

     

    There’s one important exception to LR’s general rule of ignoring time zones in metadata: The Quicktime / MP4 standard was poorly written decades ago and requires that capture time be recorded in UTC. Most non-Internet-connected cameras ignore that and record capture time in “local time” (whatever the camera’s clock was set to, since they have no idea what time zone they’re in).  But Internet-connected cameras (e.g. smart phones) typically obey the standard and record capture time in UTC and the time zone in proprietary, non-standard fields.

     

    So for videos from Apple IOS devices and one or two other manufacturers, LR will read the non-standard time zone and convert the capture time using it.

    T
    thomas5CEDAuthor
    Inspiring
    April 9, 2026

    Hi John. Thanks for the detailed reply.

    I don’t see why cameras that don’t record a time zone in EXIF would prevent LR from handling the the tag correctly from cameras that do. If the tag is missing, keep treating it as local time, if the tag is there just use it.

    Why do you say an internet connection is required for time zones? I remember pretty ancient cameras where I can manually set the time zone. 

    So I guess my best option is to either use LR’s time adjustment features or a big exiftool run to fix timezones manually?

     

    EDIT: Do you happen to know If this can be done in Lua in LR? setRawMetadata allows me to set “dateCreated” which is “ The IPTC-formatted creation date”. Is this a different date or would it allow me to implement timezone adaption as a lua script?

    johnrellis
    johnrellis
    Legend
    April 9, 2026

    Why do you say an internet connection is required for time zones? 

    I didn’t -- I said, “many cameras that aren’t connected to the Internet still don’t have a notion of time zone and don’t record time zone in EXIF”. Most recent non-connected cameras do let you set time zone manually and record it in EXIF. But some recent cameras still don’t, such as these cameras from my database of sample raws: Ricoh GR IV, DJI Air 3s and 3, DJI Mini 3, Gopro Hero 12. Leica M11.

    T
    thomas5CEDAuthor
    Inspiring
    April 8, 2026

    I think I figured out where the timestamps come from:

    LrC seems to take the dateTime part without time zone, then assumes local time zone (my current time zone is +2, CEST) and then uses that to compute the timestamps:

    2026-03-29T16:52:55+02:00 is 2026-03-29T14:52:55+0

    2026-03-29T11:52:09+02:00 is 2026-03-29T09:52:09+0

    So the timestamps seem to depend on the timezone of the lightroom importing the photo?

    This is very strange since LrC already has the correct timezone extracted in the ISO8601 versions of the same information.

     

    PS: I am pretty sure I filed this as a bug report, but it somehow got moved to questions?

    Terms & ConditionsAccessibility statement
    Using the community Terms of use Privacy Cookie preferences Do not sell or share my personal information ad choicesAdChoices