Troubleshoot date and time issues in model-driven apps

When date and time values are off by a day or a few hours, it might be caused by time zone or daylight saving adjustments. This article provides tips to troubleshoot issues such as:

• The Date and Time field shows the wrong value.
• The Date only value shows the wrong date for some users and time zones.
• The Date and Time field shows the correct value in some parts of the app, but not others.
• After changing a date and time value and saving it, it changes automatically to a different value.
• Entering a daylight saving switchover date results in the date being off by one day or the time being off by an hour.

Determine if it's a server or client issue

Model-driven apps are web apps. They get data from the Dataverse cloud service (server). The same data can power multiple apps (clients). Errors can occur on the server or client.

If the date and time value stored on the server is unexpected, it will likely appear incorrectly in all apps regardless of user or system time zone. Therefore, verifying the server value is an important first step.

Check the configuration of the date and time column

Dataverse supports different time zone adjustment behaviors for date and time columns (fields). Before troubleshooting, it's important to understand how different parts of the system process date and time values.

Check the date and time column options in the Power Apps portal or solution explorer:

• Whether it accounts for a user's time zone
• Whether it displays the time part of the value

Check if the correct value is stored on the server

Date and time values are always stored as UTC on the server. You can view the raw value on the server with a Web API query.

Here's a query to get a column for a row (record).

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

The table and column names used are logical names, not display names.

The following example gets the scheduledstart column of the appointment table for the row with ID d2862246-4763-ee11-8def-000d3a34118b.

https://myorg.crm.dynamics.com/api/data/v9.2/appointments(d2862246-4763-ee11-8def-000d3a34118b)?$select=scheduledstart

Entering this in the browser address bar will show something like the following:

{
    "@odata.context": "https://myorg.crm.dynamics.com/api/data/v9.2/$metadata#appointments(scheduledstart)/$entity",
    "@odata.etag": "W/\"11472725\"",
    "scheduledstart": "2023-10-15T07:30:00Z",
    "activityid": "d2862246-4763-ee11-8def-000d3a34118b"
}

Therefore, the scheduledstart of the appointment is October 15th, 2023, 7:30 am. The Z at the end indicates that the value is in UTC.

Let's say a user in the time zone UTC-8 views this column in a model-driven app. These are the expected values for the different column options.

If the value shown in the app isn't adjusted correctly, it's likely a client issue. If the server value is incorrect to begin with, it's likely a server issue.

Check the formatted value from the server

Time zone and daylight saving adjustments can be done on the server or in the app. If the same column shows a different value in different parts of the app, it's likely that some parts of the app are using the formatted value from the server, while others are making the adjustments in the app.

This is likely an issue. Before reporting it, you can isolate whether it's a server or client issue by checking the formatted value from the server.

For example,

GET https://myorg.crm.dynamics.com/api/data/v9.2/appointments(d2862246-4763-ee11-8def-000d3a34118b)?$select=scheduledstart
Accept: application/json
OData-MaxVersion: 4.0
OData-Version: 4.0
Prefer: odata.include-annotations="OData.Community.Display.V1.FormattedValue"

The response will include the value adjusted by the server. In this example, the user is in the UTC-8 time zone, and scheduledstart has User Local behavior. Therefore, the formatted value is eight hours behind the raw value.

{
    "@odata.context": "https://myorg.crm.dynamics.com/api/data/v9.2/$metadata#appointments(scheduledstart)/$entity",
    "@odata.etag": "W/\"11472725\"",
    "[email protected]": "10/14/2023 11:30 PM",
    "scheduledstart": "2023-10-15T07:30:00Z",
    "activityid": "2ad8786a-9164-ee11-9ae7-0022480a0700"
}

If this formatted value is incorrect, it's a server issue. If it's correct, then it's a client issue.

Investigate unexpected server values

Possible reasons for unexpected server values are:

• You might not have configured the time zone adjustment behavior and format correctly.
• Business rules and workflows running on the server can change the value before or after it's saved. Inside an app, client scripts can change the value before sending it to the server for saving.

Determine if it's a customization issue or product issue

Customizations can lead to unexpected behavior. The following methods can help rule out problems caused by customizations.

Disable custom scripts

Custom scripts frequently cause issues. Try disabling them temporarily.

Create a new date and time column

Creating a new date and time column is the easiest way to find out if the issue is caused by configuration errors or customizations like business rules. Ideally, use a different table and app.

If the new column works as expected, it's likely a customization issue. Compare with the original column to find the difference.

If the new column has the same problem, it might be a product issue. You can create a vanilla repro model-driven app and report it through a support request.

Try a different time zone

To find out if time zone and daylight saving adjustments are causing unexpected values, try changing the user's time zone.

There are two settings that affect time zones in model-driven apps:

1. Time zone in personal options.
2. System time zone. For information on how to change it, see the respective documentation in Windows, Android, iOS, or macOS.

Useful combinations to try:

• Match the time zone in personal options with the system time zone.
• Use UTC time zone.
• Use a time zone with the same offset, but doesn't observe daylight saving.

Change the "Date Only" format to "Date and Time"

If a date-only value is off by a day, it's helpful to show the time part to see if time zone adjustments could be the cause. You can temporarily change the column format in the Power Apps portal or solution explorer.

Don't use 2-digit years

The 2-digit year is ambiguous. For example, 40 might mean 1940, 2040, or 2140. How the system interprets 2-digit years can and will likely change over time.

It's also difficult to investigate when the complete date and time values aren't shown. For these reasons, it's strongly recommended to use 4-digit years, especially when entering dates.

If you can't switch to 4-digit years permanently, try it temporarily to help troubleshoot.

See also

Behavior and format of the Date and Time column