By default, workspaces are configured to the Pacific Standard Time (UTC -08:00) time zone.
You can change the default time zone and set a custom time zone in each workspace. This custom zone will be applied to reporting in the workspace. This customization enables you to deliver solutions that are sensitive to the local time zone of the workspace's users (for example, daily data that should reflect the definition of a day in the users' time zone).
In GoodData, terms workspace and project denote the same entity. For example, project ID is exactly the same as workspace ID. See Find the Workspace ID.
How Time Zones Affect Reporting
The time zone can significantly affect reporting.
The time zone set in a workspace affects how the GoodData platform determines "today" and "yesterday" that are used in the date filters. For example, a user from Europe wants to receive an insight about yesterday's activities at 7 AM every morning, and the workspace time zone is set to the default Pacific Standard Time. If the insight is created with the "Date is Yesterday" filter, it would be calculated for the day before yesterday due to the time offset between Central European Time and Pacific Standard Time. Therefore, from the system's point of view, it is still the previous day, while for the user it is the next day already.
Workspace editors and administrators may build metrics that use MAQL macros such as
THIS (see THIS Macro),
PREVIOUS (see PREVIOUS Macro), and
NEXT (see NEXT Macro), each of which is defined relative to the current date context (such as day, month, year, and so on). If these types of macros are used consistently throughout the workspace, reports/insights may be changed significantly when the time zone is modified.
Configuring a precise time zone can be very important in terms of matching the reports to the values in the system of record. For example, if your workspace and your accounting system are set to different time zones, quarterly figures may be different in the two systems if revenue that arrived at the end of the quarter is recognized in the following day (and quarter) in your workspace.
Best Practices for Setting a Custom Time Zone
- Where possible, time zones in your workspaces should match the defined time zone in your systems of record. If that is not possible, set the time zone to reflect the local time of most users of the workspace.
- As part of your data loading processes, your workspace's incoming data should be normalized to a single consistent time zone. For example, if you are collecting data from two different data sources whose data is each recorded in a different time zone, the data loading processes should normalize the incoming data streams to a single time zone. Ideally, it is this time zone that is applied within the workspace itself.
Set a Custom Time Zone
Before changing the time zone, inform users and identify the potential impacts on reports/insights. To minimize disruptions, apply the change during off-peak hours.
The time zone configuration is done through the gray pages. For more information, see Access the Gray Pages for a Workspace.
You must be an administrator in the workspace to perform this procedure.
Go to the following gray page:
The time zone page opens.
- From the dropdown, select the time zone that you want to use in the workspace.
- If you do not see the preferred time zone in the dropdown, enter a new time zone in the textbox. The time zone must be in the format specified in the IANA Time Zone Database.
The value of the time zone entered in the textbox overwrites the value of the time zone selected in the drop-down list.
- The values to use are stored in the
- UTC offset values are stored in the fifth and sixth column.
- The values to use are stored in the
- Click Submit.
The new time zone is set. All subsequent queries to the workspace return report/inisght data that reflects the new time zone.