Strange datetime behavior when using the Five9 Domo Connector

bstacy
bstacy Member
in Connectors

I am using the Domo Five9 connector to pull a report containing list data into Domo and am encountering challenges relating to datetime fields.

The two fields I am having issues with are:

Timestamp - This field tracks the date and time that a given record was added to a list.
created_date_string - This field within Five9 is actually a string representation of the date and time that a given record was added to our CRM and subsequently created within Five9.

The report within the Five9 platform has a timezone selector. When I use that selector within Five9 the timestamp data updates accordingly as expected and the created_date_string field values do not change, also as expected since within Five9 that field is a string field.

When the Domo Five9 connector pulls the data in from Five9 the Timestamp field gets added to Domo as a string field rather than a datetime, but the timestamp value that is stored is -8 hours from the timestamp value within Five9.

When the Domo Five9 connector pulls the data in from the Five9 created_date_string field, the field gets added to Domo as a datetime field, but the value that is stored is -7 hours from the created date/time value in the Five9 record.

There are several things going on here which I do not understand.

  1. Why is Domo doing any time adjustment on the Timestamp field given that Domo is storing those values in a Domo string field rather than a datetime field?
  2. Why is the value of the Timestamp field being adjusted by -8 hours? It seems to do this regardless of what timezone I configure the Five9 report to run for which leads me to believe that the connector is somehow identifying the timezone for this data as PST (i.e. perhaps the underlying data from the connector is coming in with "-8", I can't see this because I can't see the raw data from the connector).
  3. The created_date_string field being adjusted by -7 makes sense, I think, given that I believe our Domo instance is configured for a UTC-7 timezone.

I could configure this job via workbench rather than using the Five9 connector, and I've done that with other jobs in the past which might use the Five9 connector because of similar issues that I just didn't have time to dig into. However, that presents quite a few additional steps which I'd really like to avoid.

How do I troubleshoot this and if the issue exists within the underlying connector, how do I report that? Is that a Domo support issue?

And if this is a connector issue, should I just avoid using the connector entirely or is there some series of steps that I should take to account for this within my ETL workflows? I'm happy to build in additional logic, but I really want to understand why it's behaving this way so that I can feel confident that the logic I'm building in will be reliable.

Tagged:

Best Answer

  • ggenovese
    ggenovese Contributor
    Answer ✓

    I think this is a factor of whether the timestamps provided by the Five9 connector are in UTC and also what your company time zone is set to. If the time stamps are in local time and Domo is assuming they are in UTC then Domo will try to convert the time stamps to your local time defined in the company settings. Take a look at this article, it explains what is happening and suggests some solutions:

    https://domo-support.domo.com/s/article/360042934394?language=en_US

Answers

  • ggenovese
    ggenovese Contributor
    Answer ✓

    I think this is a factor of whether the timestamps provided by the Five9 connector are in UTC and also what your company time zone is set to. If the time stamps are in local time and Domo is assuming they are in UTC then Domo will try to convert the time stamps to your local time defined in the company settings. Take a look at this article, it explains what is happening and suggests some solutions:

    https://domo-support.domo.com/s/article/360042934394?language=en_US

Categories