Why is this setting causing the metadata in the final S3 bucket to mismatch the original Genesys Cloud recording properties when exporting digital channel interactions for legal discovery? We are using the /api/v2/recording/bulkexports endpoint with a filter for chat and email interactions from the last quarter. The environment is set to Europe/London timezone but the exported JSON manifests show timestamps shifted by two hours, ignoring the explicit timezone parameter sent in the request body. The bulk export job completes successfully with a status of COMPLETED, yet the chain of custody documentation generated from these files is invalid due to the timestamp discrepancy. We have verified the user token scopes include recording:read and recording:export, and the S3 bucket policy allows write access from the Genesys Cloud export service. The issue persists across multiple export jobs initiated within the same hour. Is there a known bug with the digital channel metadata serialization in the current API version, or is this a configuration issue with the regional data center settings? We need to ensure the audit trail remains intact for the ongoing litigation case. The specific error is not an HTTP failure but a data integrity issue where the ‘startTime’ field in the export manifest does not match the ‘startTime’ property of the source recording object retrieved via the single recording endpoint. Any insights on forcing consistent timezone handling in the bulk export payload would be appreciated.