I shoot with UTC time zone in camera (so I don't have to keep changing time zones on travel). I keep that UTC for my catalogues. In the several cases that this problem occurred images were shot in Central Asia (UTC +5) and LR CC pano merge shifted the time by -5 hrs for the merged image as if it were trying to force it to UTC, when it was already set that way, apparently based on the GPS location stored in the image.
Always happens, I believe. This does not happen with a merge done in LR Classic, only in LR CC, apparently. Version 2.3.
Urgently needs fixing.
I believe it happened with all the panos I made from photos taken with either a Nikon D850 (with an attached di-GPS unit) and with a Z7 connected to an iPhone XsMax via bluetooth and Nikon's SnapBridge app. They are in stacks in the Adobe Cloud. I can share a folder with you. Maybe you can contact me by the email associated with this account and I can give you the link. There are 9 D850 stacks and 13 from the Z7.
They were taken in 2 different time zones and uploaded to the cloud (via an iPad) in probably 2 Central Asian time zones and some in San Francisco and maybe Dubai. My memory is foggy but the incorrect offset wasn't only -5 hours as stated in the original post but sometimes was other maybe even a +7 (not sure) and might be dependent on the timezone of uploading...
The following information comes from Rawdigger using exiftool on the merged dng file:
Date/Time Original : 2019:04:09 16:02:04
Create Date : 2019:04:09 16:02:04
Offset Time : -07:00
Offset Time Original : +00:00
Offset Time Digitized : +00:00
Note that the Offset Time is incorrectly set to -07:00.
The following information from Rawdigger using exiftool on one of the image files that went into the merge
Create Date 2019:04:09 16:01:57
Offset Time +00:00
Offset Time Original +00:00
Offset Time Digitized +00:00
Note that here the Offset Time is correctly set to 00:00
The only thing that happened between these two different Offset Time entries was the Lightroom CC merge operation, where it appears the incorrect entry was made.
We are not able to reproduce in house - except with your raw files where a sidecar (XMP) file exists already. That sidecar file was supplied by you and to troubleshoot further we really need to know which application did the actual creation of the sidecar file.
Lightroom Classic creates sidecar files easily and on demand.
Lightroom Desktop only creates them as part of a Save To: operation.
Other programs can also create them.
Without knowing exactly how the sidecar was created and by which software (including version) we don't have a way to proceed forward.
I use only Adobe software, Lightroom Desktop and Mobile, Lightroom Classic, and occasionally Photoshop, all updated to latest versions by Creative Cloud.
Many of the image sets that exhibit this problem (including the one you have been testing) were ingested in the field by Lightroom Mobile on an iPad. Others were imported in Lightroom Desktop, None directly in LR Classic. I routinely sync images to Lightroom Classic in a catalog for which "Automatically write changes in XMP" is turned ON. It is probable that all of the stacks I shared with you had been through LR Classic synching before I merged them. LR Classic is presently at 8.3.1 and most likely was at that version when the affected stacks were synched.
Since I did not use the Save To: operation in Lightroom Desktop, it would appear that the XMP files were created during or after the sync operation in LR Classic and before the merge in LR Desktop.
I will try to reimport some of the examples from the original camera XQD cards and try to reproduce the problem before letting LR Classic touch them. I will let you know and put the images in the shared folder.
I spent several hours trying to track down where the XMP entry photoshop:DateCreated="2019-04-23T14:07:54" with no time zone offset was made.
I used Lightroom Desktop Save To: and copied one stack to another area of my disk, then deleted these files from both LRCC and LRClassic. I then imported the original raw files directly into LRCC from the XQD card, first via the iMac desktop with a card reader, then via an iPadPro and a card reader and Apple Photos, then via the iMac desktop directly from the Z7 camera. I did not touch the files with LrClassic. I merged in LRCC. In all cases the merged time zone was correct.
In the first case, I then also opened LRClassic, made an exposure curve change, and let Classic synch and closed it. Then re-opened LRCC and merged again. The time zone was correct.
In other words I was unable to reproduce the earlier result with the workflow I believe I used. When I deleted the stack (after saving them outside of LR for reference) and reimported the original saved files, a merge did result in an incorrect time zone for the dng as before.
In the XMP for one of the nef files, as you have noted, the entries are different for the case with an incorrect merged time zone and a correct one, respectively:
I am sorry I cannot tell you which app or sequence results in the entry with no time zone offset, but the fact that the tag is “photoshop” and that I am only using Adobe software suggest strongly that it is an Adobe product that (in some circumstances) does not provide a +00:00 or Z indication for the UT (GMT) time zone the camera was using.
The following is from the Wikipedia entry on the ISO 8601 standard which defines how Date/Time information is to be formatted:
“If no UTC relation information is given with a time representation, the time is assumed to be in local time. While it may be safe to assume local time when communicating in the same time zone, it is ambiguous when used in communicating across different time zones. Even within a single geographic time zone, some local times will be ambiguous if the region observes daylight saving time. It is usually preferable to indicate a time zone (zone designator) using the standard's notation.”
“An offset of zero, in addition to having the special representation "Z", can also be stated numerically as "+00:00", "+0000", or "+00”.”
The Lightroom Desktop merge operation appears to strictly follow the standard where no offset information means local time. As I noted it would seem likely that some other Adobe operation is incorrectly dropping the offset information for the UT(GMT) time zone. Given the ambiguity that the Wikipedia article notes and that one is dealing with multiple time zones in Lightroom, you might consider having the Lightroom Desktop merge operation recognize the lack of an offset as meaning Z or +00:00 (UT/GMT).
Thanks for still paying attention to this rather obscure problem.