Skip to main content

​
Intro

There are two types of time zones in Domo: personal and company. Anyone can define their personal time zone in Domo to determine when they receive alerts, notifications, and scheduled reports. Admin-level users can define a company time zone for the entire instance to standardize how visualizations display.
Note: Throughout this article, we use the following time-related abbreviations:
  • UTC (Coordinated Universal Time)
  • EST (Eastern Standard Time)
  • PST (Pacific Standard Time)

​
Personal Time Zone

You can define your personal time zone in the user settings to manage when notifications, alerts, and scheduled reports are delivered.

​
Define Your Personal Time Zone

Follow these steps to define your personal time zone:
  1. In the navigation, select your profile picture.
  2. Select Settings.
  3. Go to the Loca lization tab.
    localization tab.jpg
  4. (Conditional) Under Timezone, you can either choose your own time zone or choose to use the company time zone:
    • Expand the dropdown and choose a time zone.
      choose time zone.jpg
      In the confirmation dialog, select OK to keep your changes.
      confirm change.jpg
    • Below the Timezone dropdown, verify the company time zone and select Set as timezone.
      set at timezone.jpg
    • In the confirmation dialog, select OK to keep your changes.
      confirm change.jpg
      Note: Updating your personal time zone doesn’t offset any DATETIME data you are viewing in Domo to display in your personal time zone. Only the company time zone offsets any DATETIME data. Learn more about DATETIME considerations around Domo.

​
Company Time Zone

The company time zone is the default for the entire instance. By default, the company time zone is UTC. You do not have to define a company time zone. If all your Domo data is in the same time zone, you don’t need to set a company time zone. There are additional considerations to be aware of around defining a company time zone versus not defining one. See a list of them below.
Important: If all of your data in Domo is in the same time zone, you do NOT need to set the time zone.

​
Required Grant

To set the company time zone, you must be an Admin or have a custom role with the following grant enabled: (Admin-level) Manage All Company Settings — This grant permits the user to manage company metadata, authentication rules, security, publishing, and more.

​
Defined Company Time Zone vs. Undefined Company Time Zone

You aren’t required to define a company time zone, but there are some considerations to be aware of.
Important: Domo assumes all DATETIME data loaded into it is in UTC at loading time.For example, if a DataSet loaded into Domo has DATETIME values in PST, Domo does not register this. Conversions (like the company time zone) applied as if the data is in UTC. In our example, the data would be rendered as PST -8:00 (the difference between PST and UTC).
When there is a defined company time zone, the following is true:
  • Because Domo assumes all DATETIME data loaded into it is in UTC, if there is a defined company time zone, the data is adjusted as if from UTC to the selected time zone. If the data loaded is not in UTC, this will cause issues with how visualizations display DATETIME data. The data itself remains unchanged.
  • The difference between the company time zone and UTC is added or subtracted from all DATETIME values whenever data is:
    • Rendered for display in a DataSet preview
    • Rendered for display on a card
    • Used in a calculation
  • The Day/Week/Month date grain on cards and dashboards honors the defined company time zone.
  • Days begin at midnight for the company time zone.
  • The company time zone applies to all DataSets in Domo and does NOT affect any standard date and time values within your data; it only affects DATETIME values.
When there is not a defined company time zone, the following is true: All data displays in UTC and there is no way to convert DATETIME fields to your global corporate time. An example of DATETIME data is: 2014-08-14 15:05:30. For example, if you’re in New York City in July and your date displays in UTC, the date changes at 8:00 PM since UTC is 4 hours ahead of New York City (in the Eastern Time Zone) during Daylight Saving Time. In the same scenario in December, the date changes at 7:00 PM because UTC is 5 hours ahead of EST. See more DATETIME considerations below.

​
Define the Company Time Zone

Admins and others with the required grant can define the company time zone by following these steps:
  1. Navigate to the Admin Settings.
  2. Under Company settings, select Company overview.
  3. Under Formatting, choose an option from the Time zone dropdown.
    time zone update.jpg
  4. Select Save to keep your changes.
    save time zone.jpg

​
DATETIME Considerations Around Domo

Tip: Watch how data time zones are stored vs displayed in Domo and why it matters.
Learn about DATETIME data in various features around Domo:

​
Connecting Data

Since Domo expects that all input DATETIME values are in UTC, note the following:
  • DATETIME values are not converted to UTC during import from self-managed DataSets (such as Excel, Box, Google Sheets, or file upload). Data in these sources must be stored in UTC before import.
  • DATETIME values are not converted to UTC during import from certain connectors (such as Qualtrics, Adobe Analytics, and SurveyMonkey). However, most connectors deliver UTC values by default.
Important: Always check that values coming from any connector are in UTC to ensure time zone conversions happen correctly.
Note: If a DATETIME column is brought into Domo as a string data type rather than a DATETIME, it is not converted based on the time zone settings.

​
DataFlows and Transforms

DataFlows operate on the raw data values stored in the database, not on converted values. You receive different calculated results when grouping values with a DATETIME field in a DataFlow (raw values) compared to doing the same grouping on a card with the converted values. Dynamic date and time value functions in DataFlows and calculations are unaffected by any time zone set in your instance. The following functions will always reference UTC:
  • CURDATE()
  • CURRENT_DATE()
  • CURRENT_TIME()
  • CURRENT_TIMESTAMP()
  • CURTIME()
  • NOW()
  • SYSDATE()
Tip: You can use the SUBDATE or ADDDATE functions in Beast Modes to adjust these values as needed. See the Beast Mode Functions Reference Guide for more information.

​
Transform Time Zones with a Calculation or DataFlow

You can transform time zones with either a calculation or DataFlow, but it’s important to note that there are situations where one solution may be better than the other.
Transform with a Calculation
It’s more appropriate to transform a time zone with a calculation when the output field meets the following requirements:
  • The output field doesn’t need to be used as the Date Range Field on the card (given that you cannot currently use calculations for the Date Range Field).
  • The output field doesn’t need to be used in other calculations (this would require duplicating the transformation code in every location where the field will be used).
Adjust Calculations for Daylight Saving Time
Timestamp outputs for DataFlows are according to the company time zone of your instance. Even if the transform preview shows UTC, it will convert to your settings upon generating the output. However, timestamp functions for calculations will stamp according to UTC. This can cause issues when writing calculations off these fields/functions and if your state recognizes Daylight Saving Time. You can create a calculation to convert UTC into the correct time zone while also taking Daylight Saving Time into account. See the example below. Specifically, this formula provides the value of the date column shifted according to whether you’re affected by Daylight Saving Time.
Note: Daylight Saving Time for the United States begins at 2:00 AM on the second Sunday in March and ends at 2:00 AM on the first Sunday in November.
CASE

WHEN `date` >= ADDDATE(STR_TO_DATE(CONCAT(YEAR(`date`),'03','01'),'%Y%m%d'),(MOD(15 - DAYOFWEEK(STR_TO_DATE(CONCAT(YEAR(`date`),'03','01'),'%Y%m%d')),7) + 7))

AND `date` < ADDDATE(STR_TO_DATE(CONCAT(YEAR(`date`),'11','01'),'%Y%m%d'),MOD(1 - DAYOFWEEK(STR_TO_DATE(CONCAT(YEAR(`date`),'11','01'),'%Y%m%d')),7))

then DATE_SUB(`date`,INTERVAL 4 HOUR)

else DATE_SUB(`date`,INTERVAL 5 HOUR)

END
Transform with a DataFlow
If you’re already using a DataFlow to create the DataSet powering a card, it’s often best to adjust the time zone in the existing DataFlow. You can then use the output fields as the Data Range Field on the card or in calculations.
Convert Time Zones with a MySQL DataFlow
MySQL offers a CONVERT_TZ function that you can use to convert the time zone in a DataFlow. This function is also designed to accommodate Daylight Saving Time (DST). For example, to convert a DATETIME column from Coordinate Universal Time (UTC) to Pacific Standard Time (PST), use this function: CONVERT_TZ(`Date`, 'UTC', 'PSTUS/Pacific') Domo doesn’t provide detailed documentation on using MySQL functions. There are many resources available on the internet.

​
Schedule DataSets and DataFlows

If you have a defined company time zone, DataSet schedules are still specified using UTC values. There is a UTC label on those scheduling fields.
utc labels.jpg
Runtimes displayed in the History tab for DataSets and DataFlows always display in the time zone of the computer that you are viewing them from.
runtime format.jpg

​
Code Engine

The Code Engine editor assumes UTC while running.
image (4).png

​
Workbench

DATETIME values are not converted to UTC during Workbench uploads unless a Shift Date Timezone transform is applied to the DataSet job. See Setting the Timezone for a Workbench 5 Job. Note: Scheduled runtimes for Workbench DataSet jobs follow the clock of the machine that Workbench is installed on. Company time zone settings do not affect Workbench scheduling.

​
FAQ

This may be due to a conflict between your input data and your company time zone. Learn about the company time zone above.You can also learn how Domo handles DATETIME data.
When you schedule an update for a DataSet, the schedule is based on UTC. However, the time displayed in the update history is the actual update time based on your defined company time zone. If you see a conflict between the scheduled time and the displayed time, verify that the job is scheduled correctly using UTC.If Daylight Saving Time is an issue, you may have to update your connector schedule twice yearly to account for the change. See Adjust Calculations for Daylight Saving Time.
There are two likely causes for this:a) The most common cause is that your company time zone isn’t defined properly. Learn how to define your company time zoneabove.b) The other common cause is that your DataSet was scheduled to upload in a time zone other than UTC and your system is shifting the timestamp to align with your defined company time zone. This means Domo assumes your data is coming in as UTC, even though it isn’t.To solve this, you can either adjust your DataSet/connector upload schedule or create a calculation or DataFlow to resolve the conflict between the time zones.