排查模型驱动应用中的日期和时间问题

项目
04/02/2024

当日期和时间值在一天或几个小时前关闭时，它可能是由时区或夏令时调整引起的。本文提供了排查以下问题的提示：

“ 日期和时间” 字段显示错误值。
“ 仅日期” 值显示某些用户和时区的错误日期。
“ 日期和时间” 字段在应用的某些部分显示正确的值，但未显示其他部分。
更改日期和时间值并保存后，它会自动更改为其他值。
输入夏令时转换日期会导致日期关闭一天或关闭一小时。

确定这是服务器还是客户端问题

模型驱动应用是 Web 应用。它们从 Dataverse 云服务 (服务器) 获取数据。相同的数据可以支持多个应用 (客户端) 。服务器或客户端上可能发生错误。

如果服务器上存储的日期和时间值是意外的，则无论用户或系统时区如何，它都可能会在所有应用中错误地显示。因此，验证服务器值是重要的第一步。

检查日期和时间列的配置

Dataverse 支持日期和时间列的不同时区调整行为， (字段) 。在进行故障排除之前，请务必了解系统的不同部分如何处理日期和时间值。

在 Power Apps 门户或解决方案资源管理器中检查日期和时间列选项：

是否考虑用户的时区
是否显示值的时间部分

检查是否在服务器上存储了正确的值

日期和时间值始终以 UTC 的形式存储在服务器上。可以使用 Web API 查询查看服务器上的原始值。

下面是一个查询，用于获取行的列 (记录) 。

[Organization URI]/api/data/v9.2/<entity set name>(<row id>)?$select=<column name>

使用的表名和列名是逻辑名称，而不是显示名称。

提示

查找行 ID 的一种简单方法是在模型驱动应用中将其打开。可以在页面 URL 中找到 ID。

以下示例获取 scheduledstart ID d2862246-4763-ee11-8def-000d3a34118b为的行的表列appointment。

https://myorg.crm.dynamics.com/api/data/v9.2/appointments(d2862246-4763-ee11-8def-000d3a34118b)?$select=scheduledstart

在浏览器地址栏中输入此项将显示如下内容：

{
    "@odata.context": "https://myorg.crm.dynamics.com/api/data/v9.2/$metadata#appointments(scheduledstart)/$entity",
    "@odata.etag": "W/\"11472725\"",
    "scheduledstart": "2023-10-15T07:30:00Z",
    "activityid": "d2862246-4763-ee11-8def-000d3a34118b"
}

因此， scheduledstart 的 appointment 是 2023 年 10 月 15 日上午 7：30。 Z末尾的指示该值采用 UTC 格式。

假设时区 UTC-8 中的用户在模型驱动应用中查看此列。这些是不同列选项的预期值。

时区调整行为	格式	应用中显示的值
用户本地	日期和时间	2023 年 10 月 14 日，晚上 11：30
用户本地	仅限日期	2023 年 10 月 14 日
Time-Zone 独立	日期和时间	2023 年 10 月 15 日，上午 7：30
Time-Zone 独立	仅限日期	2023 年 10 月 15 日
仅限日期	-	2023 年 10 月 15 日

如果应用中显示的值未正确调整，则可能是客户端问题。如果服务器值开头不正确，则可能是服务器问题。

检查服务器的格式化值

可以在服务器或应用中执行时区和夏令时调整。如果同一列在应用的不同部分显示不同的值，则应用的某些部分很可能使用来自服务器的格式化值，而其他部分正在应用中进行调整。

这可能是个问题。在报告它之前，可以通过检查服务器中的格式化值来隔离这是服务器还是客户端问题。

例如，

GET https://myorg.crm.dynamics.com/api/data/v9.2/appointments(d2862246-4763-ee11-8def-000d3a34118b)?$select=scheduledstart
Accept: application/json
OData-MaxVersion: 4.0
OData-Version: 4.0
Prefer: odata.include-annotations="OData.Community.Display.V1.FormattedValue"

响应将包括服务器调整的值。在此示例中，用户位于 UTC-8 时区，并且 scheduledstart 具有 用户本地 行为。因此，格式化值比原始值落后 8 小时。

{
    "@odata.context": "https://myorg.crm.dynamics.com/api/data/v9.2/$metadata#appointments(scheduledstart)/$entity",
    "@odata.etag": "W/\"11472725\"",
    "scheduledstart@OData.Community.Display.V1.FormattedValue": "10/14/2023 11:30 PM",
    "scheduledstart": "2023-10-15T07:30:00Z",
    "activityid": "2ad8786a-9164-ee11-9ae7-0022480a0700"
}

如果此格式化值不正确，则这是服务器问题。如果正确，则这是客户端问题。

调查意外的服务器值

出现意外服务器值的可能原因包括：

你可能未正确配置时区调整行为和格式。
服务器上运行的业务规则和工作流可以在保存之前或之后更改值。在应用内，客户端脚本可以在将值发送到服务器进行保存之前对其进行更改。

确定是自定义问题还是产品问题

自定义可能会导致意外行为。以下方法可帮助排除自定义导致的问题。

禁用自定义脚本

自定义脚本经常导致问题。请尝试暂时禁用它们。

创建新的日期和时间列

创建新的日期和时间列是确定问题是由配置错误还是业务规则等自定义项引起的最简单的方法。理想情况下，请使用其他表和应用。

如果新列按预期工作，则可能是自定义问题。与原始列进行比较以找出差异。

如果新列具有相同的问题，则可能是产品问题。可以创建一个 vanilla Repro 模型驱动应用，并通过支持请求进行报告。

尝试其他时区

若要了解时区和夏令时调整是否会导致意外值，请尝试更改用户的时区。

有两种设置会影响模型驱动应用中的时区：

个人选项中的时区。
系统时区。有关如何更改它的信息，请参阅 Windows、Android、iOS 或 macOS 中的相应文档。

尝试的有用组合：

将个人选项中的时区与系统时区相匹配。
使用 UTC 时区。
使用偏移量相同的时区，但不遵循夏令时。

提示

以下方法提供了更多详细信息，以便更轻松地调查日期和时间问题。

将“仅日期”格式更改为“日期和时间”
不要使用 2 位数年份

将“仅日期”格式更改为“日期和时间”

如果仅日期值在一天内关闭，则显示时间部分以了解时区调整是否可能是原因很有帮助。可以在 Power Apps 门户或解决方案资源管理器中暂时更改列格式。

不要使用 2 位数年份

2 位数年份不明确。例如，40 可能表示 1940、2040 或 2140。系统如何解释 2 位数年份可能会而且可能会随时间而变化。

如果未显示完整的日期和时间值，也很难调查。出于这些原因，强烈建议使用 4 位数年份，尤其是在输入日期时。

如果无法永久切换到 4 位数年份，请暂时尝试它以帮助进行故障排除。

另请参阅

日期和时间列的行为和格式

通过