こんにちは。マイクロソフト サポート エンジニアの王です。
Dataverse (Dynamics 365) を利用したアプリケーション開発において、「日付」の扱いは非常に重要かつ、複雑になりがちなトピックの一つです。特に、日本時間 (JST) のような UTC (協定世界時) と時差がある環境では、「登録したはずの日付が 1 日ずれている」 といったお問い合わせをいただくことがよくあります。
今回は、日付列（フィールド）の「動作 (Behavior)」と「書式 (Format)」の組み合わせによるデータの格納され方の違いと、設定変更時の注意点について、実際の検証結果を交えて解説します。
日付列の基本概念
検証に入る前に、Dataverse の日付列における重要な設定である「タイムゾーン調整 (Time zone adjustment)」の動作について整理します。
- ユーザー ローカル (User Local)
- ユーザーのタイムゾーン設定に合わせて日時を表示・変換します。
- データベースには UTC に変換されて保存されます。
- タイムゾーンに依存しない (Timezone Independent)
- タイムゾーン変換を行いません。ユーザーが入力した値がそのまま保存され、どのタイムゾーンのユーザーが見ても同じ値が表示されます。
- 誕生日やホテルのチェックイン日など、絶対的な日付・時刻に適しています。
- 日付のみ (Date Only)
- 時刻部分を持たず、日付のみを扱います。実質的にタイムゾーン変換は行われません。
検証：JST ユーザーがデータを入力した場合の挙動
今回は、以下の構成のフィールドを用意し、JST (UTC+9) のユーザー が 「2026年1月1日 07:00」 を入力した場合に、内部データとしてどのような値が格納されるかを確認しました。
| 動作 (Behavior) | 書式 (Format) | 内部格納値 (UTC) | 解説 |
|---|---|---|---|
| ユーザー ローカル | 日付と時刻 | 2025-12-31T22:00:00Z | 入力値から 9 時間引かれた値 (UTC) が格納されます。 (2026/1/1 07:00 JST - 9h = 12/31 22:00 UTC) |
| ユーザー ローカル | 日付のみ | 2025-12-31T15:00:00Z | 注意点: 書式が「日付のみ」の場合、時刻は 00:00 として扱われます。 2026/1/1 00:00 JST を UTC に変換するため、前日の 15:00 となります。 |
| タイムゾーン非依存 | 日付と時刻 | 2026-01-01T07:00:00Z | 入力した値がそのまま格納されます。タイムゾーン変換は行われません。 |
| タイムゾーン非依存 | 日付のみ | 2026-01-01T00:00:00Z | 時刻は 00:00 となりますが、日付は入力通りです。 |
| 日付のみ | 日付のみ | 2026-01-01 | タイムゾーン変換は行われません。 |
ポイント:
「書式：日付のみ」かつ「動作：ユーザー ローカル」の組み合わせは特に注意が必要です。画面上は「2026/1/1」と見えていても、内部的には「2025/12/31 15:00」として保存されています。これを API 等で取得したり、タイムゾーンを考慮しない処理で利用したりすると、「1日ずれる」 原因となります。
重要：動作を「ユーザー ローカル」から「タイムゾーンに依存しない」へ変更する場合の注意点
運用開始後に、「やっぱりタイムゾーン変換をしたくない」という理由で、既存のフィールド設定を 「ユーザー ローカル」から「タイムゾーンに依存しない」へ変更 しようとするケースがあります。
この変更を行うと、内部に保存されている値は変わらないまま、アプリケーション側の表示ロジックだけが切り替わります。 これにより、データの見え方が意図せず変わってしまう現象が発生します。
発生する現象
例えば、動作が「ユーザー ローカル」、書式が「日付と時刻」のフィールドに、JST ユーザーが「2026/1/1 07:00」と入力し、内部的に 2025-12-31T22:00:00Z と保存されていたデータがあるとします。
このフィールドの設定を「タイムゾーンに依存しない」に変更すると、以下のようになります。
- 内部値:
2025-12-31T22:00:00Z(変更されません) - 変更後の表示ロジック: タイムゾーン変換を行わず、保存されている値をそのまま表示する。
- 画面上の表示: 2025/12/31 22:00
ユーザーから見ると、「入力したはずの日時 (1/1 07:00) が、勝手に過去の日時 (12/31 22:00) に書き換わった」 ように見えてしまいます。
特に「日付のみ」の書式で使用していた場合、内部値は 2025-12-31T15:00:00Z であったため、設定変更後は画面表示が「2026/1/1」から「2025/12/31」へと、日付が 1 日戻ってしまいます。
対処策
この設定変更を行う場合は、設定変更後にデータ修正（データ移行）を行う必要があります。
具体的には、既存のレコードに対して、ずれてしまった時間分（JST であれば +9 時間）を加算して保存し直すバッチ処理などが必要となります。
まとめ
日付フィールドを使用する際は、以下の点を設計段階で十分に検討してください。
- 利用目的の明確化:
- 「会議の開始時間」や「レコード作成日時」など、時系列としての正確なポイント が必要な場合は 「ユーザー ローカル」 を使用します。
- 「誕生日」や「記念日」、「契約日」など、世界中どこで見ても同じ日付 であるべき情報は 「タイムゾーンに依存しない」 または 「日付のみ」 を使用します。
- 「日付のみ」書式の注意:
- 書式を「日付のみ」にする場合、動作が「ユーザー ローカル」になっていると、UTC 変換により内部的に前日の日付で保存される可能性があります。特別な理由がない限り、書式が「日付のみ」の場合は、動作も「タイムゾーンに依存しない」または「日付のみ」にすることを推奨します。
- 後からの変更は慎重に:
- 動作設定の変更は、既存データの表示に影響を与えます。変更が必要な場合は、データ修正の計画も合わせて立てる必要があります。
参考情報
※本情報の内容（添付文書、リンク先などを含む）は、作成日時点でのものであり、予告なく変更される場合があります。