Time zones best practices management for daylight savings change

StyLe
StyLe Member
edited March 2023 in Datasets

Hello,

 

I have an issue regarding time zones management in Domo specifically for scheduling dataflows. If I'm right, we cannot change the time zone, that will always stay as UTC. I work in a country where we still have daylight saving time changes (France). Two weeks ago, a time change occurs and all my dataflows ran 1 hour too late and they are still running 1 hour too late cause I can't change all my dataflows each 6 months

Best Answer

  • DataMaven
    DataMaven Coach
    Answer ✓
    My workaround is to run them more frequently. Unless the etl is doing something that will impact the result if run every hour, it should be a non-issue. It's a waste of back end Domo resources, but if it concerns them, they can work on a functionality for us to schedule based on our local time zones, and have their systems do the conversion on the back end.

    In case it helps your sanity...I believe the reason it's all in UTC is to maintain alignment across global offices all on the same instance. This is excellent when you have a global team, but confusing as anything if your team is all in the same time zone.

    Would be ideal for everyone to see everything in their time zone ID by ID, but I guess that gets really complicated.

    Oh...I also recall that it would cause issues with things like the Salesforce connector and the date/time stamps imported as data. I don't recall the specifics, but when it was explained to me years ago, it sounded like it would be a nightmare to work out.
    DataMaven
    Breaking Down Silos - Building Bridges
    **Say "Thanks" by clicking a reaction in the post that helped you.
    **Please mark the post that solves your problem by clicking on "Accept as Solution"

Answers

  • StyLe
    StyLe Member

    Sorry, I forget, I have this issue with dataflows and also Domo native connectors (as Jira for example).

     

    Regards,

     

    Philippe.

  • DataMaven
    DataMaven Coach
    Answer ✓
    My workaround is to run them more frequently. Unless the etl is doing something that will impact the result if run every hour, it should be a non-issue. It's a waste of back end Domo resources, but if it concerns them, they can work on a functionality for us to schedule based on our local time zones, and have their systems do the conversion on the back end.

    In case it helps your sanity...I believe the reason it's all in UTC is to maintain alignment across global offices all on the same instance. This is excellent when you have a global team, but confusing as anything if your team is all in the same time zone.

    Would be ideal for everyone to see everything in their time zone ID by ID, but I guess that gets really complicated.

    Oh...I also recall that it would cause issues with things like the Salesforce connector and the date/time stamps imported as data. I don't recall the specifics, but when it was explained to me years ago, it sounded like it would be a nightmare to work out.
    DataMaven
    Breaking Down Silos - Building Bridges
    **Say "Thanks" by clicking a reaction in the post that helped you.
    **Please mark the post that solves your problem by clicking on "Accept as Solution"
  • Our issue is with workbench scheduled jobs: local time is Pacific, but workbench is saving jobs in UTC.

    Workbench scheduled jobs automatically change to +1 in March and -1 in November, changing schedule to an incorrect time.

     

    We were hoping changing the Company Settings time zone from UTC to local time would resolve the issue, but it didn't. I'm assuming this means the scheduled time is associated with Domo's system, and not our company instance.

     

    It appears there still isn't "functionality for us to schedule based on our local time zones", as mentioned by @DataMaven.