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

發行項
11/20/2024

當日期和時間值在一天或幾個小時前關閉時，可能是由時區或日光節約調整所造成。本文提供疑難解答問題的秘訣，例如：

[ 日期和時間] 欄位會顯示錯誤的值。
[ 日期] 值會顯示某些使用者和時區的錯誤日期。
[ 日期和時間] 字段會顯示應用程式某些部分的正確值，但不會顯示其他部分的值。
變更日期和時間值並儲存之後，它會自動變更為不同的值。
輸入日光節約切換日期會導致日期關閉一天或一小時關閉。

判斷其是否為伺服器或客戶端問題

模型驅動應用程式是 Web 應用程式。他們會從 Dataverse 雲端服務（伺服器）取得數據。相同的數據可以支援多個應用程式（用戶端）。伺服器或用戶端上可能會發生錯誤。

如果儲存在伺服器上的日期和時間值非預期，則不論使用者或系統時區為何，都可能會在所有應用程式中顯示不正確。因此，確認伺服器值是重要的第一個步驟。

檢查日期和時間數據行的設定

Dataverse 支援日期和時間數據行（fields）的不同時區調整行為。在進行疑難解答之前，請務必瞭解系統處理日期和時間值的不同部分。

在 Power Apps 入口網站或方案總管中檢查日期和時間資料行選項：

它是否為使用者的時區帳戶
它是否顯示值的時間部分

檢查正確的值是否儲存在伺服器上

日期和時間值一律會儲存為伺服器上的UTC。您可以使用 Web API 查詢來檢視伺服器上的原始值。

以下是取得數據列數據行的查詢（記錄）。

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

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

提示

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

下列範例會取得scheduledstartappointment標識符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 pm
使用者地區	只有日期	2023 年 10 月 14 日
時區不轉換	日期和時間	2023 年 10 月 15 日，7:30 am
時區不轉換	只有日期	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時區。
使用具有相同位移的時區，但不會觀察日光節約。

提示

下列方法提供更多詳細數據，讓您更輕鬆地調查日期和時間問題。

將 [僅限日期] 格式變更為 “Date and Time”
請勿使用 2 位數年份

將 [僅限日期] 格式變更為 “Date and Time”

如果僅日期值一天關閉，則顯示時間部分會很有説明，以查看時區調整是否可能是原因。您可以在 Power Apps 入口網站或方案總管中暫時變更數據行格式。

請勿使用 2 位數年份

2 位數的年份模棱兩可。例如，40 可能表示 1940、2040 或 2140。系統如何解譯 2 位數年份，而且可能會隨著時間而改變。

當未顯示完整的日期和時間值時，也很難調查。基於這些原因，強烈建議使用4位數年份，尤其是在輸入日期時。

如果您無法永久切換至 4 位數年份，請暫時嘗試以協助進行疑難解答。

另請參閱

日期及時間欄的行為與格式

共用方式為