How come this setting causes a discrepancy in the recording_date metadata field when exporting voice recordings via the bulk export API to our eu-west-1 S3 bucket for legal holds?
We are processing a high-volume discovery request requiring strict chain of custody integrity. The export jobs are initiated via POST /api/v2/recordings/bulkexport with a date range filter for the past quarter. The system reports job completion with status SUCCESS in the Genesys Cloud console. However, upon ingestion into our archival S3 bucket, a subset of the .wav files exhibits a timestamp shift of exactly +1 hour in the JSON metadata file accompanying the recording.
Our environment is configured in the eu-west-1 region, and the S3 bucket policy allows full write access from the Genesys Cloud service account. The internal clock on the BYOC edge servers is synchronized via NTP with time.google.com. The export payload includes include_metadata: true and format: wav.
The issue is not consistent across all recordings. It appears to affect calls that spanned the boundary of daylight saving time transitions or calls involving international dialing codes with significant timezone offsets. The start_time in the Genesys Cloud UI matches the call detail records (CDR), but the created_at timestamp in the S3 metadata JSON is skewed. This breaks our automated legal hold verification scripts, which expect exact millisecond alignment with the CDR end_time + processing lag.
We have verified the S3 bucket timezone configuration, which is set to UTC. The Genesys Cloud tenant is also set to UTC. Is there a known issue with how the bulk export service handles timezone normalization for recordings originating from agents in different timezones, specifically when the recording_type is voice? We need to ensure the metadata remains immutable for compliance audits. Any insights on whether this is a service-side bug or a configuration oversight in the export definition?