Thank you @Dan_Hoffman
Currently we are going with your suggestions by using customer specific Timezone instead of UTC. Will revisit this again to support multiple timezones by saving data with Granularity PT30M and UTC Timezone.

So all data is returned in UTC regardless of the time zone parameter. The time zone parameter only changes what is considered the start of the day for the day metrics but it will still be returned in UTC.

Here is how I would recommend using the bulk historical adherence endpoint. You should make sure in the request that all the management units you request have the same time zone configured, and set that as the time zone parameter. Also make sure that the startDate and endDate you provide are set to the start of day for that time zone. For example if I wanted to request yesterday's adherence for two management units in the same business unit, and that business unit was configured for the America/New_York time zone, the request body would look like this:

{
    "timezone": "America/New_York",
    "items": [
        {
            "managementUnitId": "someId",
            "startDate": "2024-11-11T05:00:00Z",
            "endDate":  "2024-11-12T05:00:00Z",
            "includeExceptions": true,
            "includeActuals": true
        },
        {
            "managementUnitId": "someOtherId",
            "startDate": "2024-11-11T05:00:00Z",
            "endDate":  "2024-11-12T05:00:00Z",
            "includeExceptions": true,
            "includeActuals": true
        }
    ]
}

This will return adherence for November 11th for those management units. Since the start of day for the America/New_York timezone for that day is 2024-11-11T05:00:00Z, there will only be a single day metric that is lined up perfectly with the requested date range.

If we aim to support multiple time zones and there isn't a granularity property like PT30M available in the request body, we need to consider how to structure our queries. For instance, if we want to retrieve adherence data for the past day in UTC, should we break the request interval into 30-minute segments?

The formula used to calculate adherence and conformance percentages can be found here:

In the web API response data, which fields/properties are being used to calculate:

1. The adherence percentage
2. The conformance percentage?"

This would help identify the specific data fields from the API response that are being used in these calculations.

In an Old genesys forum discussion, it was explained that the start date of the day is calculated by adding dayStartOffsetSeconds to startDate from the dayMetrics data. Following this same logic, how would we calculate or determine the end date of the day?

A day is defined as starting at 00:00:00 and ending at 00:00:00 of the next day in the time zone provided in your request. Note that this may or may not be exactly 24 hours - if the time zone has daylight savings rules then on the actual day of the DST transitions it will have correspondingly more or less hours, and you'll have to account for that in your own logic.

I'm not sure what you're asking regarding adherence percentage or conformance percentage.