Change the account time zone
By default, Sigma displays all date data in UTC. You can change this to display all time data according to your organization's preferred time zone using the Account time zone setting.
Requirements
- To change the account time zone, you must be assigned the Admin account type.
Select a time zone
- Go to the Administration > Account > General Settings tab.
- In the Time section, click Edit.
- In the Account Timezone dropdown, select your time zone.
If your desired time zone is not listed, contact your Account Manager or Support.
- Click Save.
Time zone change considerations
After you change the account time zone, you can expect the following:
-
Existing absolute date filters show the date range in the new time zone. For example, after switching from
UTCtoAmericas/Los_Angeles, an absolute period originally defined as starting at1/1/2021 0:00:00is displayed as starting at12/31/2020 16:00:00, the same time converted to PST. For a date during daylight savings time, like7/1/2021 0:00:00, it is displayed as6/30/2021 17:00:00. -
Existing relative date filters defined in days or less-granular units reflect the new time zone. The values for the date filters are shown the same way (e.g. 30 days ago), but the meaning changes (e.g. from midnight UTC 30 days ago to midnight Pacific Time 30 days ago).
-
Date values passed in to workbook control values via the URL are parsed according to your account time zone. You can override this default behavior so that Sigma parses the date values as being in the UTC time zone by appending a Z to the timestamp in the URL. For more information, see Workbook control values in the URL.
-
Materialized datasets do not update to the new time zone until refreshed. If you use materialized datasets, changing your account time zone might lead to temporary inconsistencies until all materializations are refreshed.
-
Data stored in time zone aware columns is interpreted according to your account time zone and changes accordingly when you change the account time zone. For example, if you insert
1/1/2021into a TIMESTAMP_TZ column in Snowflake using the UTC session time zone:- If your account time zone is set to UTC, Sigma displays it as
1/1/2021 00:00:00. - If your account time zone is set to
Americas/Los_Angeles, the same timestamp displays as12/31/2020 16:00:00.
- If your account time zone is set to UTC, Sigma displays it as
CSV files uploaded to Sigma use a time zone aware column to store time and date values. If you have previously uploaded a CSV file with a date column, it will not update to the new time zone unless the CSV is re-uploaded. Otherwise, it is converted to the same moment in absolute time for the new account time zone.
How Sigma displays date data
Sigma displays all date data according to your organization's account time zone. This has the following consequences:
-
If a column in your data platform has a stated time zone, such as a TIMESTAMP_LTZ column, Sigma interprets it in your organization’s time zone while preserving the absolute time. For example, a column with the timestamp
2025-09-10 10:00:00.000for theAmerica/New_Yorktime zone is converted to2025-09-10 07:00:00.000if your Sigma organization has theAmerica/Los_Angelesaccount time zone. -
If a column in your data platform has no time zone, such as a TIMESTAMP_NTZ column, Sigma interprets it in your organization’s time zone while preserving the written time. This means that all timestamps in Sigma display an absolute time. For example, a TIMESTAMP_NTZ column containing the timestamp
2025-09-10 00:00:00.000is interpreted as2025-09-10 00:00:00.000in the account time zone of your Sigma organization.
If you need to preserve the written time of a column in your data warehouse in Sigma, you can do one of the following:
- Convert the column to a data type without a time zone, such as TIMESTAMP_NTZ, in your data platform. Because there is no time zone to convert from, the written time is preserved when the column is added to Sigma. The column in Sigma is interpreted in the account time zone of your Sigma organization.
- Change your Sigma organization's time zone to match the time zone of the data in your data platform, so there is no conversion applied to the absolute time when interpreted in Sigma. For example, if your data platform is set to the
America/Los_Angelestime zone, you can set your Sigma organization's account time zone toAmerica/Los_Angelesto preserve the written time and absolute time of the data. This is particularly relevant the data in your data platform is TIMESTAMP_LTZ data.
Warehouse views time zone limitation
If the time zone of your Sigma organization and your data platform are different, creating a warehouse view from a Sigma element that includes date columns is not supported and can produce unexpected results.
Consider the following example scenario:
- A record in your data platform in a TIMESTAMP_NTZ column has the timestamp
2025-09-28 21:00:00.000. - Your Sigma organization is set to the
America/New_Yorktime zone. - Your data platform is set to the
America/Los_Angelestime zone. - You create a filter in Sigma for records on the date
2025-09-29.
In Sigma, the record displays as 2025-09-28 21:00:00.000-4:00. But, after creating a warehouse view, it displays as 2025-09-28 21:00:00.000-7:00 in your data platform. In both Sigma and the data platform, the filter is for the absolute time range 2025-09-29T00:00:00.000000000-04:00 to 2025-09-29T23:59:59.999000000-04:00. In Sigma, this record does not meet the filter criteria. In the data platform, it does. To resolve this issue, set the Sigma account time zone to match your data platform.
This is true for any scenario where:
- The Sigma organization and connected data platform have different account time zones.
- A calculation is performed on a date column, such as a filter targeting that column, or a calculated column that uses the date column.
Sigma creates date filters using an absolute moment in time based on your account time zone, but reads the column using session time zone. Because session time zone differs between the data platform and Sigma, the filter selects for a different set of values in each location.
Updated 5 days ago
