Orion_Rapp | 2022-03-20 23:01:51 UTC | #1
Attempting to use:
/api/v2/workforcemanagement/managementunits/{managementUnitId}/historicaladherencequery
The query we post to this api includes a timeZone value.
The resulting data (WfmHistoricalAdherenceResultWrapper) includes startOffsetSeconds for each exceptionInfo entry
We have noticed that the value for startOffsetSeconds stays the same value regardless of value for timeZone in the post's query. We have tested with "American/Chicago" and "Etc/UTC" but the resulting value of startOffsetSeconds does not change.
Using the Genesys WFM UI as a source of truth, we have noticed that if you take the startDate (date only) and add the startOffsetSeconds from the exceptionInfo, it results in an "US/Eastern" time for the schedule exception (and the Genesys WFM UI agrees with this).
Shouldn't the value of startOffsetSeconds change when the value of timeZone changes in the original post? Because the startDate value changes depending on the timeZone in the original post's query?
If not, how does one get an accurate time of when a schedule exception took place?
Can you confirm that the value of startDate (date only) + startOffsetSeconds from the exceptionInfo equals an accurate DateTime in "US/Eastern" time zone for the exception?
Many thanks, Orion
Eos_Rios | 2022-03-20 21:43:40 UTC | #2
In my experience despite the documentation the actual behavior is it uses the timeZone of the BU. This doesn't effect me because I ask for each report in the native BU TZ anyway, but if it's an impact to you I recommend submitting a customer care ticket so they can either correct the documentation, fix the problem, or explain the apparent discrepancy.
brian.trezise | 2022-03-21 13:43:32 UTC | #3
Hey Orion, thanks for reaching out.
All WFM data is returned via the api in UTC time zone, regardless of the time zone the request is entered in or even the BU time zone (The BU time zone is used internally to determine things like "what constitutes a day" and take into account things like local daylight savings time in various calculations).
The back-end server converts any input dates to UTC before processing the request, and returns all data in UTC.
In order to get the exception time in your time zone you must first convert startDate from the default UTC before calculating the startDate + startOffsetSeconds. Most date/time libraries will do the time zone conversion for you.
Also note that dates are returned in ISO-8601 format which includes the time zone of the date, so a library will be able to deserialize the string to the correct time zone then you can adjust as needed
brian.trezise | 2022-03-21 13:40:23 UTC | #4
Also in case it's helpful, here's a handy tutorial for the historical adherence API. Currently only available in Java but the general steps will be the same regardless of which language you're using.
Retrieving Notifications from a Historical Adherence Query
system | 2022-04-21 13:41:20 UTC | #5
This topic was automatically closed 31 days after the last reply. New replies are no longer allowed.
This post was migrated from the old Developer Forum.
ref: 13977