Genesys Cloud - Developer Community!

Hi community,

I'm currently building a Botflow and I need to ask the customer for a timeslot during the day. The slot works fine, the resulting timestamp is in UTC like everything in Architect. Normally I would have no issues converting it to the local timezone, however:

Suppose the current local time is 3 o'clock, which is 1:00 UTC.

• if the customer says something like "at 6", the resulting slot will contain "06:00:00" which I have to use as 6 o'clock local (customer's) time
• if the customer says something like "three hours from now", which also means 6 o'clock in local time, the resulting slot will contain the value "04:00:00", since it is calculated as 1 o'clock UTC + 3 hours.

If I always add the offset between UTC and local timezone to the result, the result in the first scenario will be wrong.

If I don't convert it, the second one is wrong.

Any ideas?

#Architect #Bots 

------------------------------
Florin Cosmin Radulescu
Genesys - Employees
------------------------------

Hey Florin,

I found an easy answer to this one.

I noticed that the seconds of the time collected by the spoken time was always "00", where the time collected by saying "three hours from now" had the exact seconds e.g. "43".
I then did a simple Decision to see if the seconds equal "0". In the false path I adjusted the slot time by adding/subtracting the timezone offset hours (found via data action).

Hope this helps anyone who might come across the same problem... 

Hi Florin,

Another approach that has worked for us in a callback bot is to avoid applying the timezone offset directly to the slot value.

Instead, we convert the current UTC time to the customer’s local timezone (for example Melbourne) so we have the correct local date. For example:

Flow.LocalDateTime = AddHours(GetCurrentDateTimeUtc(), ToInt(Flow.TimeZoneOffset/60))

We then construct the datetime using that local date together with the hour and minute provided by the customer.

This way the customer can simply say something like “6 pm” or “6:15”, and it resolves correctly as local time, regardless of whether the expression was absolute (“at 6”) or relative (“three hours from now”). The final value can then be converted back to UTC if needed.

In our case we capture the minutes as well, so callbacks can be distributed throughout the hour rather than all being scheduled exactly on the hour.

We implemented this in a digital callback bot, but the same approach should work in a voice bot flow as well since Architect stores DateTime values internally in UTC.

Hope this helps.