Working with time zones
The Results app displays datetime data using the time zone you have set in your user profile in Launchpad, but there are a few exceptions.
How Results determines your time zone
Your time zone depends on how you access the data in the Results app.
- If you are logged into Diligent One, you see the time zone you set in your user profile in Launchpad.
- If you are not logged into Diligent One (for example, you are viewing data someone has shared with you), you see the time zone set in Launchpad for that instance. If the data you are viewing belongs to another company or instance, that instance's time zone may be different from your instance's time zone.
Changing your time zone
- For help changing your user time zone, see Update your profile.
- For help changing your instance's time zone, see Updating instance's settings.
Why time zones matter
Imagine you work for a company with offices in Vancouver, London, and Singapore. Company policy requires you to process new records within 48 hours, and records usually need input from people in different offices. You rely on the difference between a record's creation date and updated date to monitor its age. However, due to time zone differences, employees in Vancouver begin their working day as employees in London end theirs. For employees in Singapore, it is already the next day.
You need to know the exact age of a record from the standpoint of your time zone to ensure compliance and avoid confusion when you are sharing a data set with someone around the world.
Example of a record created in Singapore and processed in Vancouver
| Created | Updated | Calculated age | |
|---|---|---|---|
| Local times | January 10, 08:00 (Singapore) | January 11, 17:00 (Vancouver) | 33 hours |
| UTC time | January 10, 00:00 UTC | January 12, 01:00 | 49 hours |
From Vancouver, it looks like the record is 33 hours old. However, due to the 16-hour time difference between Vancouver and Singapore, the record is actually more than 48 hours old, causing non-compliance.
Example of a record created in London and processed in Singapore
| Created | Updated | Calculated age | |
|---|---|---|---|
| Local times | January 20, 06:00 (London) | January 21, 20:00 (Singapore) | 38 hours |
| UTC time | January 20, 06:00 UTC | January 21, 12:00 UTC | 30 hours |
From Singapore, it looks like the record is 38 hours old and will reach 48 hours before the next work day begins. You stay late to finish it, but you do not need to. Due to the 8-hour time difference between London and Singapore, the record is only 30 hours old. It could have been processed by someone in London or Vancouver during their normal work hours.
How Results solves time zone differences
The Results app reflects your time zone for data in datetime fields. This includes Results metadata like when a record was updated and when it was closed. Because the underlying data is never altered, others see the same data in the time zone that makes sense to them. If necessary, you can change your time zone (for example, if you are traveling or need to standardize on another time zone). This applies throughout the app, including interpretations, metrics, and visualizations.
Time zone shifting adjusts for Daylight Savings Time (DST) when it is active in your time zone.
Time zone shifting is not applied to:
- Fields with time type. When you import data in the Results app, keep dates and times in the same column. If you are importing from Analytics, import fields with a datetime type. If you are importing from a file, combine dates and times into one column if they are not already combined. For more information about formatting dates and times, see Supported data types.
- Triggers running on a scheduled frequency. Each trigger has its own time zone, chosen when the trigger was created. Triggers also adjust for DST when it is active in that trigger's time zone.
- Data in questionnaires.
