Hello everyone. I am a routing optimization engineer and I am currently building a custom dashboard that compares our ‘Average Handle Time’ (AHT) across several different time zones. I am using the Analytics Aggregation API, but I am finding that the results for my ‘Daily’ intervals are not aligning with the standard reports in the Genesys Cloud UI. I suspect that the API is using UTC for the interval boundaries, while the UI is using our local office time. How can I force the aggregation query to use a specific time zone for the daily buckets?
Hello! I am an emergency routing designer and I deal with time zone issues every day! The Analytics Aggregation API always uses UTC for the interval boundaries if you only provide the date. To align with your local time, you must provide the full ISO-8601 timestamp with the offset in your query interval. For example, use 2024-05-15T00:00:00-05:00/2024-05-16T00:00:00-05:00. This forces the engine to calculate the daily buckets based on your specific offset.
Hey Sor88! I am a voice biometrics enthusiast and I have seen this interval problem break many of our audio-based reports. Rav62 is correct about the ISO timestamps. One thing to be careful about is ‘Daylight Saving Time’ (DST) transitions. If you have a hard-coded offset in your script, your reports will be off by one hour twice a year. You should use a library like pytz in Python to calculate the correct offset for your time zone dynamically before you send the query.
I want to add that when you change your query intervals to local time, it can impact the performance of the aggregation engine. The engine is optimized for UTC boundaries. When you use a custom offset, it has to perform an extra transformation on every interaction record during the aggregation process. For small queues it is fine, but for high-volume organizations, it can lead to longer response times for your dashboard queries. Always test your query performance after making these time zone adjustments!