Power Apps date off by one day? Fix the date picker time zone

You pick 14 October in a canvas app, save, and a colleague sees 13 October. Or the date is right for you and wrong for everyone in another country. Microsoft's troubleshooting page for canvas apps opens with exactly this complaint: values that are off by a day, or by a few hours, which Microsoft says time zone or daylight saving adjustments might cause. When a Power Apps date is off by one day, look for an adjustment made twice, or not at all, somewhere between the database and the screen. The fix is to find where, then make the data source and the date picker agree.

This guide covers canvas apps. For dates inside a cloud flow, see Power Automate formatDateTime and time zones.

Why a date moves by a day

Most data sources keep dates and times in UTC. A "date" usually isn't a bare date at all: it's a date with a time of midnight, and midnight in one place is the previous evening somewhere west of it.

Power Fx describes two kinds of date and time value:

• User local: stored in UTC, and shown and entered in each person's own time zone. The same moment looks different to someone in Canada and someone in Japan.
• Time zone independent: shown and entered the same way everywhere, whatever the time zone.

Inside the app, a canvas app holds every date and time value in UTC and converts it for display. Its Date data type is a date without a time, in the app user's time zone. A Date value can still carry a time, usually midnight, and the app holds it as a UTC moment.

Here's how that moves a date, starting from Microsoft's Dataverse example. A person in UTC-8 enters 14 October 2023 in a model-driven app, in a User local column with the Date only format. The time is taken as midnight, so Dataverse saves 2023-10-14T08:00:00Z: their midnight, in UTC. Now work it through for a colleague in UTC-10 who opens the same record. For them, 08:00 UTC is 22:00 on 13 October, so they see 13 October. Nothing is broken; the column was told to adjust for time zones, and it did.

Two more things to know:

• The time zone comes from different places. For User local values, canvas apps use the time zone of the browser or device. Model-driven apps use the time zone in the person's Dataverse personal options. The settings usually match; when they don't, the two apps show different dates for the same record.
• The date picker adjusts too. Both the classic and the modern date picker controls have a DateTimeZone property, set to Local (the person's time zone) or UTC. That's a second place where an adjustment can be added or skipped.

Step 1: check the value that's stored

Look at the raw value before you touch a formula. If it's already wrong in the data source, every app will show it wrongly, and the fix belongs at the source, not in the canvas app.

For Dataverse, read the column with a Web API query in the browser's address bar, using the table's entity set name, the row's ID and the column's logical name:

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

The reply shows the stored value, such as "2023-10-15T07:30:00Z". The Z at the end means UTC. A column with the Date only behaviour comes back as a plain date, such as 2023-10-15. You can find a row's ID in the address of the row when you open it in a model-driven app.

For Microsoft Lists, Excel and other sources, Microsoft points you to that source's own documentation for how it stores dates.

Step 2: match the column to the date picker

Microsoft's troubleshooting page for canvas apps names a mismatch between the data source and the date picker's DateTimeZone as a common mistake. For a User local column its answer is clear: with DateTimeZone set to UTC, the person sees the UTC value, not their local time. So for a User local column, leave the picker on Local.

For a Time zone independent column, two Microsoft Learn pages describe different results in canvas apps:

Neither page explains the difference, so check which behaviour your app shows, using steps Microsoft documents:

1. Read the stored value with the Web API query in step 1.
2. In the app, show the full value with its time in a temporary label, for example Text( ThisItem.DueDate, DateTimeFormat.LongDateTime ).
3. Change the time zone of your device or computer (canvas apps use the system time zone), open the app again, and compare.

If the app shows the stored date and time in every time zone, you're seeing what the data types page describes. If it moves when the time zone changes, you're seeing the shift the troubleshooting page describes, and the picker's DateTimeZone is the setting to look at.

Check the picker's DateTimeZone property. On the modern Date picker, the values are DateTimeZone.Local, the default, and DateTimeZone.UTC.

The behaviour belongs to the Dataverse column itself; Microsoft calls it the column's time zone adjustment. Our Dataverse schema guide suggests choosing Date only for dates without a time when you create the column.

Step 3: show the hidden time and the offset

A date-only display hides the time that's causing the trouble. Microsoft's advice is to show the time part while you investigate. One way is a temporary label on the screen or in the gallery, with its Text property set to the full value in UTC:

Text( ThisItem.DueDate, DateTimeFormat.UTC )

DateTimeFormat.UTC converts the value to UTC, based on the person's time zone, and writes it in ISO 8601 form, such as 2020-04-08T03:26:59.180Z. In a User local column, a date-only value whose time isn't 00:00:00 was probably saved as someone's local midnight, then converted to UTC.

Then show the person's offset from UTC:

TimeZoneOffset()

TimeZoneOffset returns the number of minutes between the person's local time and UTC. For someone in Pacific Standard Time it returns 480. The date picker and Power Fx use this same offset for their own adjustments, so you can work out whether the value was adjusted once, twice or not at all.

If you need to convert by hand, Microsoft documents the pattern with DateAdd. Adding the offset turns a local time into UTC; subtracting it turns UTC into local time:

// Local time to UTC
DateAdd( Now(), TimeZoneOffset(), TimeUnit.Minutes )

// A UTC value in StartTime to the person's local time
DateAdd( StartTime, -TimeZoneOffset( StartTime ), TimeUnit.Minutes )

Pass the value to TimeZoneOffset, as in the second line, so the offset is the one for that date and not for today. The two can differ either side of a clock change.

Step 4: fix it at the source

Once you know where the shift happens, change the setting that causes it rather than patching every screen.

A custom Dataverse column that never needs a time, such as a birthday or a due date: change its behaviour from User local to Date only. A Date only column stores the date with no time and no time zone conversion, so everyone sees the same day. Know what you're changing first:

• This is the column's behaviour, not its format. A Date only format still stores a time; a Date only behaviour doesn't.
• It's a one-time change that can't be undone. Other apps, plug-ins or workflows that relied on the time zone adjustment might stop working correctly.
• It applies to values added or changed afterwards. Existing values stay as they were stored, in UTC; converting them might need a developer's help.
• Before you change it, review the business rules, workflows, calculated columns and rollup columns that use the column. Afterwards, open each one and save it again.
• In a managed solution you can only change it if you're the publisher, and the publisher can block the change.

A Dataverse column that needs a time, the same everywhere, such as a hotel check-in time: Microsoft suggests Time zone independent. Check how your canvas app shows it first, as in step 2.

SQL Server: datetime and datetime2 columns carry no time zone, so canvas apps assume they're UTC and treat them as User local. If the values are meant to be time zone independent, correct them with TimeZoneOffset, as in step 3. A datetimeoffset column keeps its own offset, which the app uses. When the app writes, it always writes UTC.

Daylight saving and two-digit years

Two smaller causes produce the same symptom:

• Clock changes. A date entered on the day the clocks change can come out a day or an hour wrong. On that day, one hour doesn't exist and another happens twice, and apps handle those times differently. Test with dates either side of a change.
• Two-digit years. "40" could mean 1940, 2040 or 2140, and how the system reads it can change over time. Use four-digit years, especially where people type dates.

To test a time zone problem without travelling, change the time zone of the device or computer: canvas apps use the system time zone.

Sources

• Troubleshoot date and time issues in Power Apps canvas apps — Microsoft Learn
• Troubleshoot date and time issues in model-driven apps — Microsoft Learn
• Behavior and format of the date and time column — Microsoft Learn
• Data types: Date, Time, and DateTime — Microsoft Learn
• DateAdd, DateDiff, and TimeZoneOffset functions — Microsoft Learn
• Text function: predefined date/time formats — Microsoft Learn
• Date Picker control (classic) — Microsoft Learn
• Date picker modern control in canvas apps — Microsoft Learn