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

项目
11/20/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 中的用户在模型驱动应用中查看此列。这些是不同列选项的预期值。

时区调整行为	Format	应用中显示的值
用户当地时间	日期和时间	2023 年 10 月 14 日下午 11:30
用户当地时间	仅限日期	2023 年 10 月 14 日
时区无关	日期和时间	2023 年 10 月 15 日上午 7:30
时区无关	仅限日期	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 位数年份，请尝试暂时帮助进行故障排除。

另请参阅

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

通过