How to change the timezone in photo metadata?

[davidkotz]

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 · Accepted solution]

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

[davidkotz]

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

[johnrellis]

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.

[WSHRocDoc]

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!

[Swarby]

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.

[dimensionless99]

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.

[DenisPac]

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

[melisssssssaaaaaaa]

You rock!!!!!! thank you

[johnrellis]

"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.]

[DenisPac]

Hi @johnrellis,

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

[johnrellis]

"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.]

[DenisPac]

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