Dataverse Date & Time columns: a practical guide

The two settings that matter

• Format: Date only or Date and time.

• Behavior: User Local, Date Only, or Time zone independent.

These decide storage, conversion, and what users see.

Behavior matrix

Format	Behavior	Stored as	What users see	Use when
Date only	Date Only	Pure date (internal 00:00 placeholder, no UTC conversion)	Same calendar day for everyone	Business dates that must not shift (start/end dates, birthdays)
Date only	User Local	00:00:00 UTC of the chosen day	UI shows the chosen day; scripts may show prior/next day when inspected as a Date	Avoid unless legacy requires it
Date & time	User Local	UTC instant	Local clock time per user; day can differ across zones	Real moments (meetings, execution times)
Date & time	Time zone independent	As entered, no UTC conversion	Same clock time and day for everyone	Fixed wall-clock times (e.g., “store closes 17:00”)

Concrete examples (America/Vancouver, UTC−08)

1) Date only + Date Only

• You set on UI: Nov 6.

• Dataverse stores: date = 2025-11-06 (no UTC math).

• Others see: Nov 6 in every time zone.

• If a script formats a local-midnight placeholder to ISO, it will print 2025-11-06T08:00:00Z. That ISO string is client-side formatting only; storage remains a pure date.

2) Date only + User Local

• You set on UI: Nov 6.

• Dataverse stores: 2025-11-06 00:00:00Z.

• Others see: form shows Nov 6.

• If you inspect the value as a JS Date in Vancouver, it appears as Nov 5, 16:00 (UTC→local conversion). This is why cross-field copies can drift a day if you treat it like a local midnight instant.

3) Date & time + User Local

• You set on UI: Nov 6 00:00 local.

• Dataverse stores: 2025-11-06 08:00:00Z.

• Others see: different local times by zone; near midnight, some users may see a different calendar day.

4) Date & time + Time zone independent

• You set on UI: Nov 6 00:00.

• Dataverse stores: Nov 6 00:00 with no UTC conversion.

• Others see: Nov 6 00:00 everywhere.

• If a client converts that local-midnight value to ISO, it prints 2025-11-06T08:00:00Z in Vancouver; that is display formatting, not storage.

Decision guide

1. Do users need their own local clock time?

• Yes → Date & time + User Local. Avoid setting times near 00:00 to reduce cross-zone day flips.

• No → continue.

2. Is this a date without a time-of-day?

• Yes → Date only + Date Only.

• No → Date & time + Time zone independent.

Cross-field and integration rules

• Copy Date only → Date only (both Date Only): stays the same day.

• Copy Date only (User Local) → anything: risk of day drift if you pass around a Date object. Move date parts (YYYY-MM-DD), not an instant.

• Copy Date & time (User Local) → Date only: truncation uses the reader’s local view; results can differ across zones.

Power Automate and APIs

• Date Only: compare and pass YYYY-MM-DD. Do not add times.

• User Local: normalize with explicit conversions when filtering or comparing across zones.

• OData: use yyyy-MM-dd for Date-only filters; use UTC instants for User Local Date & Time.

DST and midnight edges

• User Local near DST changes can jump or skip an hour.

• Time zone independent ignores DST; it preserves the wall-clock time.

• If you must use User Local, prefer hours well away from midnight (for example, ≥09:00).

Bottom line

• Most business dates: Date only + Date Only.

• Real moments: Date & time + User Local.

• Fixed wall-clock times for everyone: Date & time + Time zone independent.

• Avoid Date only + User Local unless you have a specific legacy reason.