【Dataverse】列の書式「日付のみ」のタイムゾーン調整に関する注意点【Power Apps】

Dataverseで日時型の列を追加するとき、列の型と書式を設定する項目がデフォルトで表示されています。しかし、高度なオプションを開くと、それとは別に「タイムゾーンの調整」という項目があることをご存知でしょうか。

この設定は高度なオプションに隠れているため見落としがちですが、この設定を理解せずに列を作成してしまうと、意図しない挙動が発生することがあります。

【結論】書式を「日付のみ」にしたときはタイムゾーンの調整も「日付のみ」に設定すべし

タイムゾーンの調整は、デフォルトでは「タイムゾーン非依存」になっています。

書式を「日付と時刻」に設定している場合は「タイムゾーン非依存」のままで問題ありませんが、書式を「日付のみ」にした場合は、タイムゾーンの調整も「日付のみ」に変更しないと、意図したデータが取得できない可能性があります。

これから、その理由について詳しく解説していきます。

データを日付のみにすべき場面

日付のみを扱うべき代表的な場面として、誕生日が挙げられます。

例えば1990年4月1日が誕生日の人がいたとします。その人の誕生日は1990年4月1日という、時刻やタイムゾーンに依存しない「日付」という概念です。

生まれた瞬間の時間（例：1990年4月1日 16時31分10秒）ではありませんし、「日本生まれである私の誕生日に該当する期間は、1990-03-31T15:00:00Zから1990-04-01T14:59:59.999999Zだね」とも言わないでしょう。

このように日付という概念では、タイムスタンプのように時間軸のある1点だったり、幅を持つ時間として表すのが不適切なことがあります。

日付のみを表すデータ型があるかどうかは言語やプラットフォームによって異なります。例えばJavaやPythonでは日付・時刻・日時にそれぞれ別の型が用意されているのに対し、JavaScriptやSwiftでは日時を表す型しか用意されていません。

DataverseとPower Appsの場合は、「日付と時刻」型と「日付のみ」型が別物として定義されています。

列の「書式」と「動作」は別の設定項目

日付のみの列を作成したいとき、通常は「書式」の設定項目を「日付のみ」にすると思いますが、それだけでは不十分です。書式の設定はあくまで見た目を変更するものであり、完全に日付のみしか保持しないデータ型にはなっていません。

Dataverseの設定画面とMicrosoft Learnで名称が異なるため少しややこしいのですが、日付型・日時型の列には以下の設定項目が存在します。

書式だけを変更しても、Dataverse内部で保有しているのは「日時型」のデータです。

タイムゾーンや時刻に影響を受けない日付を格納したい場合は、タイムゾーンの調整を「日付のみ」に変更する必要があります。

タイムゾーンの調整で選べる3種類と挙動の違い

それぞれの項目と、実際にDataverse・Power Appsで「2025年9月1日」を登録した場合の挙動を見ていきます。

Power Appsからレコードを登録する際には、以下の関数をボタンのOnSelectに設定して実行しました。

Patch(
    日付型列比較テスト,
    { ID: Blank() },
    {
        日付のみ: Date(2025, 9, 1),
        タイムゾーン非依存: Date(2025, 9, 1),
        ユーザーローカル: Date(2025, 9, 1),
        '日付名（テキスト列）': "2025年9月1日（Power AppsからPatch）"
    }
)

図で表現すると以下のようになります。

ユーザーローカルとタイムゾーン非依存は、日本標準時またはUTCの1日の開始時刻という「点」を表しているのに対し、日付のみはタイムゾーンや時刻にとらわれない1日という概念を表していることが分かります。

ユーザーローカルは非推奨

まず、ユーザーローカルはDataverse内部で期待された値が保存されていないことが分かります。日本の2025-09-01T00:00:00+0900を基準にしているため、そこからUTCとの+9時間の時差を引いた2025-08-31T15:00:00Zが保存されています。

Microsoft Learnでも、書式「日付のみ」とユーザーローカルの組み合わせは避けるように注意が書かれています。

日付のみの 形式を ユーザー ローカル 動作で使用することは避けてください。 異なるタイム ゾーンのユーザーには異なる日付が表示される場合がありますが、ほとんどのシナリオでは意図されていません。

https://learn.microsoft.com/ja-jp/power-apps/maker/data-platform/behavior-format-date-time-field#usage-guidelines

（じゃあ、そんな選択肢は始めから設定できないようしろよって感じなんですが）

タイムゾーン非依存と日付のみの違い

1日の開始時刻の点であるタイムゾーン非依存と、時刻情報を持たない日付のみでは、実務上どのような差があるのでしょうか。

Microsoft Learnでは以下のように書かれています。

日付のみ 形式の タイムゾーンに非依存 動作は、日付のみ と実質的に同じです。 将来的に時刻部分が必要かどうか不明な場合は、前者を使用してください。

https://learn.microsoft.com/ja-jp/power-apps/maker/data-platform/behavior-format-date-time-field#usage-guidelines

しかし、これは嘘です。

少なくとも開発者目線では大きく異なるため、安易にタイムゾーン非依存を選択してはいけません。

先ほどの表で、Power Appsで認識される型が「日付のみ」は日付（Date）型であるのに対し、「タイムゾーン非依存」は日時（DateTime）型になっていることにお気づきでしょうか。

この違いによって、Power AppsからFilterやLookUp関数でデータを検索する際に不都合が生じます。

実際の検索での問題事例

データテーブルコントロールを3つ作り、3種類の列でそれぞれDate(2025, 9, 1)に一致するレコードにFilterするように設定しました。

// DataTableDateOnly.Items
Filter('日付型列比較テスト', 日付のみ = Date(2025, 9, 1))

// DataTableTimeZoneIndependent.Items
Filter('日付型列比較テスト', タイムゾーン非依存 = Date(2025, 9, 1))

// DataTableUserLocal.Items
Filter('日付型列比較テスト', ユーザーローカル = Date(2025, 9, 1))

結果は以下のように、タイムゾーン非依存を条件にしたテーブルだけ、確かに存在するはずの2025年9月1日を見つけられませんでした。

Power Appsのライブ監視でネットワークを監視してみると、このテーブルからのデータ取得要求ではDataverseに以下のようなクエリを投げていることが分かりました。

filter=cr073_timezoneindependent+eq+2025-08-31T15%3A00%3A00.000Z

Filterの条件にはDate(2025, 9, 1)を指定したはずなのに、なぜか異なる値になっています。

これはPower Appsの日付型・日時型の設計やタイムゾーン設定の仕様によるものです。

Power Apps キャンバスアプリ内では実行しているデバイスのシステムタイムゾーンが自動適用されます。そして、Power Appsの日付型（Date型）は、実行環境の0:00:00の日時と同義であると解釈します。

これらの仕様により、システムタイムゾーンが日本であるデバイスで実行したDate(2025, 9, 1)の結果は日本時間の2025年9月1日 0:00（2025-09-01T00:00:00+0900）になります。

そして、Dataverseでは内部ではすべての日時データをUTCで保存しているため、それに合わせてコネクタで通信する際に2025-09-01T00:00:00+0900は2025-08-31T15:00:00Zに自動変換されてしまうのです。

それに対し、Dataverse内部で時刻情報を持たない日付のみ列に対するクエリは以下のようになります。

filter=cr073_dateonly+eq+2025-09-01

タイムゾーンの変換を行わずに2025年9月1日のデータを探してきてくれます。

以上のことから、タイムゾーンや時刻を考慮しない「日付」という概念を保存したい場合は、タイムゾーンの調整を「日付のみ」に設定するのが適切です。

書式「日付のみ」＋動作「タイムゾーン非依存」の組み合わせで発生する矛盾

また、先のセクションで出した表にも不思議な点があることにお気づきでしょうか。

Power Apps キャンバスアプリ内では実行しているデバイスのシステムタイムゾーンが自動適用されるため、私の実行環境である日本で2025-09-01T00:00:00Zを取得したらPower Appsでは2025年9月1日 9:00とならなければおかしいのではないでしょうか。

これはライブ監視でも挙動を掴めなかったので確証はありませんが、Power Appsでデータソースの情報を事前に取得し、その際列のメタデータ（DateTimeAttributeMetadata.DateFormat）がDateOnlyを示す0になっている場合は、Power Appsが取得したデータの時刻情報を切り捨てて0:00:00に整形するような仕様になっているのではないかと推測されます。

しかし、このような整形をしてしまったら同じデータとは言えません。

この無理やりな仕様のせいで、以下のような実験をすると常識では考えられないような状況が成立します。

LookUpでタイムゾーン非依存列でDateTime(2025, 9, 1, 9, 0, 0)と一致するデータを検索し、第3引数でタイムゾーン非依存列のデータ（日時型）のみを取り出すように指定します。こうすることで、タイムゾーン非依存列に保存された2025-09-01T00:00:00Zのデータを検索にヒットさせることができます。

そして、LookUpで取得した日時型データとDateTime(2025, 9, 1, 9, 0, 0)を等価演算子で比較します。

結果はなんとfalseになります。DateTime(2025, 9, 1, 9, 0, 0)と一致するデータがDateTime(2025, 9, 1, 9, 0, 0)と一致しないという意味不明な状況です。

// この式はfalseになる
LookUp(日付型列比較テスト, タイムゾーン非依存 = DateTime(2025, 9, 1, 9, 0, 0), タイムゾーン非依存) = DateTime(2025, 9, 1, 9, 0, 0)

この不可解な事象は、以下のような処理を経ることによって発生します。

もはやバグと言っていいレベルではないかと個人的に思っています。

タイムゾーン非依存の列を後から他の動作に変更することはできない

タイムゾーンの調整はユーザーローカルから他の動作への変更にしか対応していないため、デフォルト状態であるタイムゾーン非依存で作成してしまった列の動作を、作成後に日付のみに変更することはできません。

そのため、列の作成時にその列の要件を十分に考慮した選択が必要です。

最後に

Power AutomateやSharePointでも日時・タイムゾーンに関する問題にはよく遭遇しますが、Dataverseにも特有の問題があるんですね……。

Microsoft製品に限らず、プログラム上での日時の取り扱いは、開発者の理解不足でよくバグを発生させる領域なので注意していきたいところです。

参考文献

• Column data types in Microsoft Dataverse – Power Apps | Microsoft Learn
• Microsoft Dataverse における日付と時刻の列の動作と形式 – Power Apps | Microsoft Learn
• DateTimeFormat EnumType (Microsoft.Dynamics.CRM) | Microsoft Learn