モデル駆動型アプリの日付と時刻の問題のトラブルシューティング

  • [アーティクル]

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

  • [日付と時刻] フィールドに間違った値が表示されます。
  • [日付のみ] の値には、一部のユーザーとタイム ゾーンの間違った日付が表示されます。
  • [日付と時刻] フィールドには、アプリの一部の部分では正しい値が表示されますが、それ以外の部分は表示されません。
  • 日付と時刻の値を変更して保存すると、自動的に別の値に変更されます。
  • 夏時間切り替え日を入力すると、日付が 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をscheduledstart持つ行の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"
}

したがって、 scheduledstartappointment は 2023 年 10 月 15 日 7:30 am です。 末尾の は 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"
}

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

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

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

  • タイム ゾーン調整の動作と形式が正しく構成されていない可能性があります。
  • サーバーで実行されているビジネス ルールとワークフローは、保存前または保存後に値を変更できます。 アプリ内では、 クライアント スクリプトは 、保存のためにサーバーに送信する前に値を変更できます。

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

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

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

カスタム スクリプトは、頻繁に問題を引き起こします。 一時的に無効にしてみてください。

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

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

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

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

別のタイム ゾーンを試す

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

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

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

試してみるのに役立つ組み合わせ:

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

ヒント

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

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

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

2 桁の年を使用しない

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

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

4 桁の年に完全に切り替えることができない場合は、トラブルシューティングに役立つ一時的な方法をお試しください。

関連項目

[日付と時刻] 列の動作と形式