P: Lightroom should preserve OffsetTime attribute in DNG files

Report · Jul 14, 2023

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-met...

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.

Report · Jul 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.

Report · Nov 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!

Report · Nov 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

Report · Aug 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)?

Report · Aug 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

Report · Aug 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

Report · Aug 31, 2014

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

LR (except for one point release several years ago) won't overwrite any digitization date/times you might have set for those images. If you had set digitization date/times separately from capture times using some other software, LR will preserve them.

Report · Apr 23, 2019

I've had a similar problem to Dave's when trying to merge iPhone photos into Lightroom and then export a merged collection back to Apple Photos for sharing. When I exported the images using a jpg format the result in Photos was chronologically scrambled. Based on John's excellent discussion I realized that the culprit was probably my choice to export as a jpg, rather than Lightroom or Apple. Indeed, when I export as a tiff the problem goes away and the images show up in their correct time zone. Thanks, John!

Report · Jan 15, 2020

I think this is definitely a Lightroom bug or at least a feature request, still in 2020. Searching for a fix, this thread was the top result for my google search and the marked Answer doesn't solve it for me, but I have a solution that fixes my specific problem:

THE PROBLEM:

1. Lightroom ignores the original photo's timezone and changes it in the EXIF data to the current timezone of your computer when you export out of Lightroom. The specific EXIF ID I'm reffering to is: APP1 > IFD > EXIF > 36880 OffsetTime +08:00

2. Lightroom doesn't offer any option to view or edit that EXIF field, at least with JPG files, I haven't check on RAW files yet. I'm running into this problem editing JPGs from an old Nikon DSLR, but also new JPGs shot on a new Android phone that's recording GPS and everything else.

This results in your Lightroom edited photos having inaccurate time and getting sorted out of chronological order when uploading to photo libraries like Google Photos.

MY SOLUTION:

Before you export out of Lightroom, change your computer's timezone to the timezone of where you shot your photos.

I'm on Windows 10 and I haven't tested this on Mac yet, so perhaps it's just a Windows explorer problem where it's relying on that specific Exif "timeoffset" metadata. And maybe it's not even Lightroom that's writing to that metadata field, maybe it's Windows that's writing to that field when the jpg file is created. But for Google Photos, that appears to the be the field that matters.

Report · Apr 07, 2020

Thank you so much for this trick! I have recently merged a collection of photos from two different phones and my DSLR, taken in Japan. Both phones automatically adjusted time and time zone while in Japan, but I forgot to change the timezone on my DSLR. I used Lightroom to edit capture time, but I was puzzled when I uploaded my exported jpegs to a Google Photos album and it was obvious that my DSLR pictures were at the wrong place. I quickly pinpointed the problem because Google Photos does show the timezone metadata AND apparently uses it to offset all the pictures by that many hours when sorting an album. I could have changend the capture time in Lightroom again to account for that, but it feels wrong to have the "wrong" capture time and the "wrong" timezone just for both wrong pieces of metadate to cancel each other out.

Anyway, I tried your tip and it works! Thanks a lot.

Report · Mar 01, 2021

Hello everybody,

I felt into the same issue LR setting the time zone to the current one set up on my computer, and removing the value from EXIF ID TimeZoneOffset tag.

My own solution is to use Geosetter (with exiftool in the background) to set back the correct time zone.

But this is really a pity that LR doesn't handle this value correctly in exported jpg files.

By the way I'm also using Geosetter to geotag my images before importing them into LR. More convenient in my opinion.

Regards,

Denis

Report · Oct 23, 2022

You rock!!!!!! thank you

Report · Nov 16, 2024

More than 4 years later this is unfortunately still the only workaround unless you want to edit the EXIF data separately after the export.

Report · Mar 01, 2021

"But this is really a pity that LR doesn't handle this value correctly in exported jpg files."

I think it's unlikely Adobe will ever change LR to recognize the EXIF:TimeZoneOffset tag -- it was never part of the EXIF industry standard, only a few cameras generated it, and it's poorly defined (it only allows offsets in units of hours, while over a billion people live in a time zone that's +5:30).

The EXIF 2.31 revision (2016) finally added the OffsetTime* tags for correctly recording time zones, but unfortunately LR doesn't preserve it on export. See this feature request:

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

Please add your constructive opinion to the feature request and be sure to click Like and Follow at the bottom of the first post. That will make it a little more likely that Adobe will consider implementing the feature and you'll be notified when they do.

[Use the blue reply button under the first post to ensure replies sort properly.]

Report · Jul 15, 2024

The link to the feedback/idea no longer works, however, it appears that LrC v13.4 does appear to recognise the 'OffsetTime' tag. It then adds that offset to 'exif:DateTimeOriginal' in XMP files.

Report · Jul 15, 2024

Thanks for pointing this out. Feature requests with fewer votes didn't get copied over in the migration from the old feedback forum, but someone resubmitted the request here:

https://community.adobe.com/t5/lightroom-classic-ideas/p-lightroom-should-preserve-offsettime-attrib...

Report · Jul 15, 2024

Moderators, @Rikk Flohr: Photography, please merge with this Idea and mark it as Implemented:

https://community.adobe.com/t5/lightroom-classic-ideas/p-lightroom-should-preserve-offsettime-attrib...

Report · Mar 02, 2021

Hi @John R Ellis,

OK I better understand the issue, and also the concern when the time zone offset is not in full hours (I have not faced this issue yet).

I will then reply to the other post you mention (raised 4 years ago) where it make more sense to implement a tag that has been officially defined in the latest EXIF 2.31 specs. Note that the link of the EXIF 2.31 specs you mentionned at that time doesn't work anymore.

I would then correct my statement you quoted with a more generic:

"But this is really a pity that LR doesn't handle any time zone offset value in exported jpg files."

Thanks,

Denis

Report · Mar 02, 2021

"the link of the EXIF 2.31 specs you mentionned at that time doesn't work anymore"

Thanks, I updated it to point at a copy in the Internet Archive. These standards organizations don't seem to care very much about making their standards widely accessible. (At least CIPA doesn't charge hundreds of dollars, as ISO often does.)

[Use the blue reply button under the first post to ensure replies sort properly.]

Report · Mar 03, 2021

"Thanks, I updated it to point at a copy in the Internet Archive."

The new link redirects to the newest EXIF 2.32.

Looks like the original EXIF 2.31 is not accessible anymore.

But as you said, this is already a good thing that this standard is free of charge.