次の方法で共有

モデル駆動型アプリの日付けに関する問題のトラブルシューティング

  • [アーティクル]

日付と時刻の値が 1 日または数時間でオフになっている場合は、タイム ゾーンまたは夏時間調整が原因である可能性があります。 この記事では、次のような問題のトラブルシューティングに関するヒントを提供します。

  • Date と Time フィールドに正しくない値が表示されます。
  • Date のみ値には、一部のユーザーとタイム ゾーンの間違った日付が表示されます。
  • Date と Time フィールドには、アプリの一部の部分では正しい値が表示されますが、それ以外の部分は表示されません。
  • 日付と時刻の値を変更して保存すると、自動的に別の値に変更されます。
  • 夏時間の切り替え日を入力すると、日付が 1 日ずつオフになるか、時刻が 1 時間オフになります。

サーバーまたはクライアントの問題かどうかを判断する

モデル駆動型アプリは Web アプリです。 Dataverse クラウド サービス (サーバー) からデータを取得します。 同じデータが複数のアプリ (クライアント) に電力を供給できます。 サーバーまたはクライアントでエラーが発生する可能性があります。

サーバーに格納されている日付と時刻の値が予期しない場合は、ユーザーまたはシステムのタイム ゾーンに関係なく、すべてのアプリで正しく表示されない可能性があります。 そのため、サーバー値の確認は重要な最初の手順です。

日付と時刻の列の構成を確認する

Dataverse では、 日付列と時刻列 (フィールド) に対して、さまざまなタイム ゾーン調整動作がサポートされています。 トラブルシューティングを行う前に、 システムプロセスの日付と時刻の値のさまざまな部分を理解することが重要です。

Power Apps ポータルまたはソリューション エクスプローラーで日付と時刻の列のオプションを確認します。

  • ユーザーのタイム ゾーンを考慮するかどうか
  • 値の時間部分を表示するかどうか

正しい値がサーバーに格納されているかどうかを確認する

日付と時刻の値は、常に UTC としてサーバーに格納されます。 Web API クエリを使用して、サーバー上の生の値表示できます。

行 (レコード) の列を取得するクエリを次に示します。

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

使用されるテーブル名と列名は 名前であり表示名ではありません。

ヒント

行の ID を見つける簡単な方法は、モデル駆動型アプリで開く方法です。 ID はページ URL にあります。

次の例では、ID d2862246-4763-ee11-8def-000d3a34118bを持つ行のappointment テーブルのscheduledstart列を取得します。

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"
}

そのため、appointmentのscheduledstartは 2023 年 10 月 15 日午前 7 時 30 分です。 末尾の Z は、値が UTC であることを示します。

たとえば、タイム ゾーン UTC-8 のユーザーが、モデル駆動型アプリでこの列を表示するとします。 これらは、さまざまな列オプションで想定される値です。

タイム ゾーン調整の動作 形式 アプリに表示される値
ユーザー ローカル 日時 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 は User Local 動作を持っています。 したがって、書式設定された値は生の値から 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"
}

この書式設定された値が正しくない場合は、サーバーの問題です。 正しい場合は、クライアントの問題です。

予期しないサーバー値を調査する

予期しないサーバー値の考えられる原因は次のとおりです。

カスタマイズの問題か製品の問題かを判断する

カスタマイズ によって予期しない動作が発生する可能性があります。 次の方法は、カスタマイズによって発生する問題を除外するのに役立ちます。

カスタム スクリプトを無効にする

カスタム スクリプトは、多くの場合、問題を引き起こします。 一時的に表示を停止してみてください。

新しい日付と時刻の列を作成する

新しい日時列の作成は、構成エラーやビジネス ルールなどのカスタマイズによって問題が発生しているかどうかを調べる最も簡単な方法です。 理想的には、別のテーブルとアプリを使用します。

新しい列が期待どおりに動作する場合は、カスタマイズの問題である可能性があります。 元の列と比較して、違いを見つけます。

新しい列に同じ問題がある場合は、製品の問題である可能性があります。 バニラ 再現モデル駆動型アプリを作成しサポート要求を通じて報告することができます。

別のタイム ゾーンを試す

タイム ゾーンと夏時間の調整によって予期しない値が発生しているかどうかを確認するには、ユーザーのタイム ゾーンを変更してみてください。

モデル駆動型アプリのタイム ゾーンに影響する設定は 2 つあります。

  1. 個人オプションのタイム ゾーン。
  2. システム タイム ゾーン。 変更方法については、Windows、Android、iOS、または macOS のそれぞれのドキュメントを参照してください。

試してみるのに便利な組み合わせ:

  • 個人用オプションのタイム ゾーンとシステム タイム ゾーンを一致させます。
  • UTC タイム ゾーンを使用します。
  • 同じオフセットを持つタイム ゾーンを使用しますが、夏時間は観察されません。

ヒント

次の方法では、日付と時刻の問題を簡単に調査できるように、詳細を提供します。

"日付のみ" 形式を "日付と時刻" に変更する

日付のみの値が 1 日ごとにオフになっている場合は、タイム ゾーンの調整が原因であるかどうかを確認するために、時刻部分を表示すると便利です。 Power Apps ポータルまたはソリューション エクスプローラーで列の形式を一時的に変更できます。

2 桁の年を使用しない

2 桁の年はあいまいです。 たとえば、40 は 1940、2040、または 2140 を意味します。 システムが 2 桁の年を解釈する方法は、時間の経過と同時に変化する可能性があります。

また、完全な日付と時刻の値が表示されない場合を調査することも困難です。 このような理由から、特に日付を入力するときは、4 桁の年を使用することを強くお勧めします。

4 桁の年に永続的に切り替えることができない場合は、一時的に試してトラブルシューティングを行います。

関連項目

日時の列の動作と形式