使用时区
结果应用程序使用您在启动面板的用户配置文件中设置的时区显示日期时间数据，但有一些例外情况。
结果应用程序如何确定您的时区
您的时区取决于您如何访问结果应用程序中的数据。
- 如果您已登录到 Diligent One，则会在启动面板中的用户个人资料中看到自己设置的时区。
- 如果您未登录到 Diligent One（例如，您正在查看某人与您共享的数据），则会在启动面板中看到为该实例设置的时区。如果您正在查看的数据属于其他公司或实例，则该实例的时区可能与您的实例的时区不同。
更改您的时区
为什么时区很重要
假设您为在温哥华、伦敦和新加坡均设有办事处的公司工作。公司政策要求您在 48 小时内处理新记录，而记录通常需要来自不同办事处的人员的输入。您依靠记录的创建日期和更新日期之间的差异来监控其时龄。但是，由于时区差异，温哥华的员工开始工作时，伦敦的员工已经结束了他们的工作。对于新加坡的员工来说，这已经是第二天了。
您需要从您时区的角度了解记录的确切使用期限，以确保合规性并避免在与世界各地的人共享数据集时产生混淆。
在新加坡创建并在温哥华处理的记录示例
| 已创建 | 已更新 | 计算的时龄 | |
|---|---|---|---|
| 当地时间 | 1 月 10 日 08:00（新加坡） | 1 月 11 日 17:00（温哥华） | 33 个小时 |
| UTC 时间 | 1 月 10 日 00:00 UTC | 1 月 12 日 01:00 | 49 个小时 |
从温哥华来看，这一记录似乎才保存 33 个小时。但是，由于温哥华和新加坡之间的时差为 16 小时，这一记录实际上已超过 48 个小时，因此不合规。
在伦敦创建并在新加坡处理的记录示例
| 已创建 | 已更新 | 计算的时龄 | |
|---|---|---|---|
| 当地时间 | 1 月 20 日 06:00（伦敦） | 1 月 21 日 20:00（新加坡） | 38 个小时 |
| UTC 时间 | 1 月 20 日 06:00 UTC | 1 月 21 日 12:00 UTC | 30 个小时 |
从新加坡来看，这一记录似乎已经保存 38 个小时，且在下一个工作日开始前将达到 48 个小时。您打算熬夜完成它，但您不需要这么做。由于伦敦和新加坡之间的时差为 8 小时，这个记录实际才保存 30 个小时。它可能已经被伦敦或温哥华的某一员工在其正常工作时间内处理过。
结果应用程序如何解决时区差异
结果应用程序反映了日期时间字段中数据的时区。这包括结果应用程序元数据，比如记录何时更新以及何时关闭。由于基础数据从未被更改，因此其他人会在时区中看到对他们有意义的相同数据。如有必要，您可以更改时区（例如，如果您正在出差或需要在其他时区进行标准化）。这适用于整个应用程序，包括解释、度量和可视化效果。
当在您的时区中激活时区转换时，时区转换会调整夏令时（DST）。
时区更改不适用于：
- 具有时间类型的字段。当您在结果应用程序中导入数据时，请将日期和时间保留在同一列中。如果您要从 Analytics 导入，请导入具有日期时间类型的字段。如果您要从文件导入，请将日期和时间合并到一列中（如果尚未合并）。有关格式化日期和时间的详细信息，请参阅支持的数据类型。
- 触发器按预定频率运行。每个触发器都有自己的时区，可在创建触发器时选择。在触发器的时区中激活时，触发器也会调整 DST。
- 调查问卷中的数据。
