5 Dataverse Date Fields and the Date Picker in Canvas Apps

Within Dataverse we can configure date fields in 5 different ways. When we use these fields in a Power Apps Canvas App they will behave slightly different. Today on the SharePains chat I was asked about the Modern Date Picker control and the Time Zone Independent setting. In this post I’m looking at all of the options.

Please note that within this post I’m using the UK time formats. this means that the 28 January 2026 will appear as 28/01/2026

Modern Date picker vs Classic Date picker

Is there a difference between the Modern Date picker and the Classic Date picker? Do they behave differently? As I was asked about the Modern date picker I will compare the different behaviours in both.

Date Fields in Dataverse

Within my table I’ve created 5 different date fields they all have slightly different settings. The fields are all named using the following pattern:

DateAndTime{Format}{TimeZoneSetting}

Then within the Canvas App however I’ve got more settings that may affect the way dates work. For the Modern Controls we have the date picker’s Date time zone that can be set to either Local or UTC.

For the Classic Datepicker we have the same Date time zone setting that can also be set to Local and UTC.

My Example Dates app

I’ve created an app that creates records in my Dataverse Table that looks like this. When pressing the button both my forms get submitted and records are created.

Within my Dataverse table I can see that for both Classic and Modern forms we end up with the same result. Phew that seems to be working.

When we use the app to now read the data back so that we can for example update a record, then all will be ok as long as our users work within the same time zone.

Apps working across different time zones

But if we travel to a different time zone and we open our record then we get a slightly different result. This is often considered wrong but is it really?

I’ve updated my app a bit and added another Modern Form to my app, however this time I’m setting the controls within the form all to user local. I’ve made the app save my data using the forms and then I’m reading the data back to the form.

The user who sites in the +1 hour time zone read the data that was written by the app in the +0 hour time zone. And this is the result:

We will need to take a closer look at this. I don’t think that the modern and classic controls behave in a different way here.

Setting the Controls to User Local

When the controls within my form are set to User Local, we are seeing the expected result for all types of date fields. My current date is always set to 29 January and the times match the expected times.

Setting the Controls to UTC

In the example shown above the middle form gives some unexpected results.

For User Local Date fields we are seeing that the time displayed in the app changes and matches the time within the users time zone. So where the record was initially created with a time of mid night, when we read this record in a time zone of +1 hour, we are seeing 1 am for this record. This is what you would expect to see.

For the Time Zone Independent fields with Controls set to UTC, we are getting strange behaviours.

It looks like the date part of the date picker controls correct the time zones, At midnight on 29 January 2026 it is 28 January 11pm within the other time zone. Hence the date changes to 28/01/2026.

If we assume that this is what is happening for a moment, then why does the time remain 00:00 for Date and Time fields? This feels like a bug to me. however the bug is not the date part of the Date picker, the way the time is displayed is the real issue.

The Fix

Now I don’t like putting fixes in place to controls, but if you really need to use the UTC setting for the date picker control then you could update the DefaultSelectedItems property on the control that returns the hours to the user.

[Text(Hour(Parent.Default),"00")]

However that is most likely going to cause more trouble in the long run.

Final thought

An additional complexity will be when you have developers sitting within the UTC zone as they will not see any time zone related issues with converting time between their local time and the UTC time. This typically results in users complaining and developers telling them that the issue doesn’t exist.