Skip to main content
Participant
August 31, 2014
Question

P: Lightroom should preserve OffsetTime attribute in DNG files

  • August 31, 2014
  • 2 replies
  • 6639 views

 

Posting a new request since the feature request link at :

https://feedback.photoshop.com/conversations/lightroom-classic/lightroom-preserve-new-exif-231-tags-... 

 

referenced in this discussion :

https://community.adobe.com/t5/lightroom-classic-discussions/how-to-change-the-timezone-in-photo-metadata/td-p/6429833

 

appears to be broken at this point.

 

Per the discussion, Lightroom's behavior is to write OffsetTime in DNG files based on the local time zone of the PC.  As a workaround, I've used exiftool to overwrite the DNG file's OffsetTime with the correct timezone that the photo was taken in.  however, when I "update metadata" in lightroom, it ignores the offsettime that I set in the DNG file and writes it back to the PC's time zone, so I have to do it all over again.

 

If lightroom doesn't have a well defined way to set time zones, can it at least assume that the OffsetTime in the DNG file is correct and not change it?  Then fixing OffsetTime can be a one-time manual thing.  Not sure if this was the feature request referenced above.

 

 

2 replies

johnrellis
Legend
July 15, 2024

@aks100 points out that LR 13.4 preserves EXIF:OffsetTime, OffsetTimeOriginal, and OffsetTimeDigitized in exported files and preserves the time zone offset in the corresponding fields in XMP sidecars. This was apparently added in the last year.

Participant
November 16, 2024

This is not correct. Even LR 13.5 Lightroom still sets OffsetTime based on the time zone the computer it runs on is set to, even overwriting the original (correct) value. This is definitely a bug, as the value cannot be manipulated in LR, the software should also simply not touch it. The time zone of my computer has no relation to the pictures I am exporting!

johnrellis
Legend
November 16, 2024

@magical_operator2097, "Even LR 13.5 Lightroom still sets OffsetTime based on the time zone the computer it runs on is set to...This is definitely a bug."

 

My LR 14.0.1 is obeying the standard. EXIF:OffsetTime is the time-zone offset for EXIF:DateTime, which is when a conforming app last modified the photo or its metadata. (The name "DateTime" misleads many into thinking it's the capture date.) When LR exports a photo, it correctly sets EXIF:DateTime and EXIF:OffsetTime to when the photo was exported. But LR preserves EXIF:DateTimeOriginal / OffsetTimeOriginal (capture date) and EXIF:DateTimeDigitized / OffsetTimeDigitized (when the image was converted to digital form).  

 

I've attached an original photo APC_1614.dng and an exported JPEG, APC_1614.jpg. Here's the output from Exiftool, showing the correct field values. Note that Exitool renames EXIF:DateTime to be EXIF:ModifyDate:

 

$ exiftool -a -G -modifydate -offsettime -offsettimeoriginal -offsettimedigitized /Users/john/Pictures/2024/2024-11-07/APC_1614.dng 
[EXIF]          Modify Date                     : 2024:11:08 21:35:14
[EXIF]          Offset Time                     : -05:00
[EXIF]          Offset Time Original            : -05:00
[EXIF]          Offset Time Digitized           : -05:00

 

 

 

$ exiftool -a -G -modifydate -offsettime -offsettimeoriginal -offsettimedigitized APC_1614.jpg
[EXIF]          Modify Date                     : 2024:11:16 13:57:34
[EXIF]          Offset Time                     : -08:00
[EXIF]          Offset Time Original            : -05:00
[EXIF]          Offset Time Digitized           : -05:00

 

 

 

 

Inspiring
August 31, 2014

After returning from a recent trip out west, I forgot to change my camera's timezone to the local time.  As a result, hundreds of photos from a long weekend trip were recorded with the wrong timezone.  I imported them to Lightroom 5 and discovered the problem.  Of course, I used the Edit Capture Time feature as described in the online help: https://helpx.adobe.com/lightroom/help/metadata-basics-actions.html#change_the_photo_capture_time

But that changes the time of each photo's metadata, rather than the timezone.  There's a subtle difference; the better solution would be to change the timezone so that all future interpretations and exported times would be correct.  For example, here's the original metadata from a RAW image:

DateTimeOriginal                : 2014:08:23 09:13:45

Timezone                        : -07:00

and here's what appears on an exported JPG file, after the capture time was edited:

DateTimeOriginal                : 2014:08:23 11:13:45

TimeCreated                     : 11:13:45

DigitalCreationTime             : 09:13:45

DateTimeCreated                 : 2014:08:23 11:13:45

DigitalCreationDateTime         : 2014:08:23 09:13:45

[These metadata reports were produced by exiftool.]  Notice how the RAW image includes Timezone (though sadly the JPG export does not).  More to the point, look at the variety of timestamps produced for the JPG file, none of which mention the timezone and two of which have the wrong time (9:13am instead of 11:13am).  Without the timezone information the latter is hard to interpret and looks inconsistent.  Is this a bug in LR5?  or is it a missing feature (to not record the timezone on export)?

johnrellis
Legend
August 31, 2014

There's not a simple explanation of the behavior you're observing.  It's not a bug -- LR is doing a reasonable job of following imperfect industry standards. 

The photo/camera industry in general does not make it easy to deal with time zones. LR's general approach is to preserve whatever time zones are present in the metadata but otherwise ignore them -- it doesn't change them, and it doesn't display them. As you discovered, the Edit Capture Time command does not let you change time zone, but it does preserve whatever time zones are present in the metadata  (but see below for one exception).   LR's handling of time zones conforms with Metadata Working Group's Guidelines For Handling Image Metadata 2.0, an industry standard supported by Adobe, Apple, Canon, Microsoft, Nokia, and Sony.

The EXIF metadata inserted by cameras does not provide an official field to record time zone (folklore among metadata geeks is that one of the technical leaders of the spec, when challenged about that, asked why anyone would want time zones).  Some cameras insert the non-industry-standard EXIF field TimeZoneOffset.  I don't know the entire history of this field, but it's not defined in the EXIF 2.2 or 2.3 specs, nor mentioned in the Metadata Working Group's Guidelines For Handling Image Metadata 2.0.  The field is not well-defined -- it only allows offsets of whole hours, whereas over a billion people live in a time zone whose offset is +5:30 (India). 

LR preserves EXIF:TimeZoneOffset in your original photo, but it otherwise ignores the field, and it doesn't get copied to exported photos.  This is not unreasonable, given that the field is non-standard.

The XMP metadata fields, typically inserted by software applications, do support time zones, but including a time zone is optional.  LR preserves XMP time zones that are present when the image is imported, even if you change the date/time with Edit Capture Time.  Your original photo did not contain any XMP fields (cameras typically don't insert XMP), so there were no time zones there for LR to preserve.

The Digital Creation date/time fields you observed are intended to record when an image was digitized.  With digital cameras, that's generally the same as capture time, but with scanned images, the date/time of digitization (scanning) is different from the date/time the image was originally captured.  LR's handling of these two different date/times isn't great, but it's adequate for most users.  LR will insert the digitization date/time when an image is first imported (if it doesn't already exist), but Edit Capture Time changes just the capture time, not the digitization date/time.  (A few years ago Adobe changed Edit Capture Time in a point release to also change digitization date/time, on the theory that LR is designed for images from digital cameras, and the two date/times should always be the same; but a number of users who also used LR to manage scanned images complained loudly that LR was overwriting precious metadata, and Adobe backed out that change in the next release.)

So Edit Capture Time will leave photos taken by digital cameras with an incorrect digitization date/time.  But very few users care about that -- it's only users with scanned images who care about the difference, and at least LR will avoid overwriting digitization date/time.

A suggestion for using Exiftool to examine image metadata: Use the "-a -G" options, which causes Exiftool to show which section of the metadata the fields are coming from.   Given the complexity of the legacy metadata industry standards, this will help you better understand what your camera and software tools are doing.  For example:

[EXIF]          Modify Date                     : 2014:08:31 10:01:45

[EXIF]          Date/Time Original              : 2014:08:13 11:53:44

[EXIF]          Create Date                     : 2014:08:13 08:53:44

[IPTC]          Date Created                    : 2014:08:13

[IPTC]          Digital Creation Date           : 2014:08:13

[XMP]           Modify Date                     : 2014:08:31 10:01:45-07:00

[XMP]           Create Date                     : 2014:08:13 08:53:44

[XMP]           Metadata Date                   : 2014:08:31 10:01:45-07:00

[XMP]           Date Created                    : 2014:08:13 11:53:44

[Composite]     Date/Time Created               : 2014:08:13 11:53:44

[Composite]     Digital Creation Date/Time      : 2014:08:13 08:53:44

Inspiring
August 31, 2014

Awesome! Though it appears there is no perfect solution. I appreciate the quick and thorough response. I suppose I'll just have to live with it-- and remember to reset my camera's timezone before and after travel.

My LR library includes a lot of scanned images (over 5,000) so I'll have to puzzle over the timestamps on those later.

It also includes 8,000 photographs taken in India, so your point about half-hour timezones also resonates with me!

dave