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.