針對模型驅動應用程式中的日期和時間問題進行疑難解答

發行項
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>

使用的數據表和數據行名稱是邏輯名稱，而不是顯示名稱。

提示

尋找數據列標識碼的簡單方法是在模型驅動應用程式中開啟它。您可以在頁面 URL 中找到識別碼。

下列範例會取得 scheduledstart 標識碼為之 appointment 數據列 d2862246-4763-ee11-8def-000d3a34118b的數據表數據行。

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 具有 使用者本 機行為。因此，格式化值比原始值落後八小時。

{
    "@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 位數年份，請暫時嘗試以協助進行疑難解答。

另請參閱

日期和時間數據行的行為和格式

共用方式為