Fix Date & Time Problems in Your Power Apps: A Troubleshooting Guide

Table of Contents

When working with date and time values in Power Apps, particularly model-driven apps connected to Dataverse, users sometimes encounter discrepancies. These issues often manifest as values being off by a day or a few hours. Such inaccuracies are frequently linked to how time zones, daylight saving time adjustments, or formatting are handled across the system. Understanding the potential causes is the first step in effectively resolving these challenges.

Common symptoms of date and time issues include a field displaying an incorrect value, a date-only field showing the wrong date for certain users or time zones, or inconsistencies where the same value appears correctly in one part of the application but incorrectly elsewhere. Furthermore, unexpected changes can occur after saving a record, or specifically around daylight saving time transitions where dates might shift by a day or times by an hour. These problems can significantly impact data accuracy and user trust in the application.

Determine if it’s a Server or Client Issue¶

Model-driven apps function as web applications, relying on data retrieved from the Dataverse cloud service (the server). This server data can be consumed by various apps and clients. Therefore, date and time errors can originate either on the server side or within the client application that is displaying or processing the data. Identifying the source of the problem is crucial for efficient troubleshooting.

If a date and time value is stored incorrectly on the Dataverse server, it will likely appear wrong in all client applications, regardless of the user’s time zone or system settings. Consequently, verifying the value as it exists on the server is a fundamental first step in diagnosing the problem. Dataverse supports different time zone adjustment behaviors for date and time columns (fields), such as User Local, Time-Zone Independent, and Date Only. Familiarizing yourself with how these behaviors influence value storage and retrieval is essential before delving deeper into troubleshooting.

It is important to examine the configuration of the date and time column in the Power Apps portal or solution explorer. Pay close attention to whether the column is configured to account for a user’s time zone and whether it is set to display the time part of the value or just the date. Incorrect configuration here is a common source of display issues. The column behavior dictates how the server stores and processes the time component relative to UTC, while the format affects how it is displayed to the end-user.

Check if the Correct Value is Stored on the Server¶

All date and time values in Dataverse with a time component are consistently stored in Coordinated Universal Time (UTC) format on the server, regardless of the column’s behavior setting (User Local or Time-Zone Independent). The adjustment to the user’s local time or display format happens during retrieval or within the client application based on the column configuration and user settings. You can directly inspect the raw value stored on the server using a Web API query. This method bypasses any client-side logic or formatting, giving you the definitive server-side UTC value.

A standard Web API query structure to retrieve a specific column for a particular row (record) is as follows:

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

Remember that you must use the logical names for both the table (entity set) and the column, not their display names. These logical names are consistent identifiers within the Dataverse schema. Finding the row ID is straightforward; you can typically find it within the URL of the record when viewed in a model-driven app, or you can query for it.

As an illustrative example, let’s retrieve the scheduledstart column from the appointment table for a specific row with a known ID, say d2862246-4763-ee11-8def-000d3a34118b. The logical name for the appointment table is appointments. The query would look like this:

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

Executing this query, perhaps by pasting it into your browser’s address bar (after authenticating), will return a JSON response. A typical response format showing the raw UTC value would be similar to this:

{
    "@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"
}

In this response, the "scheduledstart": "2023-10-15T07:30:00Z" line shows the value stored on the server. The Z at the end signifies that this time is in UTC. This confirms that the appointment is scheduled for October 15^th, 2023, at 7:30 am UTC. This raw value is the single source of truth on the server before any time zone adjustments are applied for display purposes.

Now, let’s consider how this UTC value (2023-10-15T07:30:00Z) should be displayed to a user located in the UTC-8 time zone. The expected display value depends entirely on the column’s behavior and format settings configured in Dataverse.

Time zone adjustment behavior	Format	Expected Value shown in the app (for user in UTC-8)
User Local	Date and time	October 14th, 2023, 11:30 pm
User Local	Date only	October 14th, 2023
Time-Zone Independent	Date and time	October 15th, 2023, 7:30 am
Time-Zone Independent	Date only	October 15th, 2023
Date only	- (Date Only)	October 15th, 2023

Note: The “Date only” column behavior is unique and does not store any time information, only the date part as UTC, and is generally treated as Time-Zone Independent.

If the value displayed in the Power App does not match the expected value based on the table above and the user’s time zone and the column’s behavior, it indicates a likely client-side issue in how the app is performing or interpreting the time zone adjustment. Conversely, if the raw UTC value retrieved directly from the server via the Web API query (2023-10-15T07:30:00Z in our example) is already incorrect according to the intended data, then the issue lies with the server or the process that originally saved the data.

Check the Formatted Value from the Server¶

Time zone and daylight saving time adjustments can be applied either by the Dataverse server before sending the data to the client or within the client application itself after receiving the raw UTC value. Sometimes, inconsistencies in how a value is displayed across different parts of an application (e.g., a form versus a grid) can occur if some components are using the server-formatted value while others are performing the adjustment client-side. This difference in handling can lead to discrepancies.

To isolate whether the formatting and adjustment logic on the server is correct, you can request the formatted value directly from the Dataverse Web API. This is achieved by including a specific Prefer header in your API request. This header instructs the server to include annotations, such as the formatted value, alongside the raw data.

Here is an example Web API GET request to retrieve both the raw and the server-formatted value for the scheduledstart column, specifically requesting the formatted value annotation:

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 server’s response to this request will include both the raw UTC value and an additional property containing the server-generated formatted string. Let’s continue with our example where the user is in the UTC-8 time zone and the scheduledstart column has the User Local behavior configured. The expected response would be similar to this:

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

Notice the "scheduledstart@OData.Community.Display.V1.FormattedValue": "10/14/2023 11:30 PM" line. This is the value that the Dataverse server calculated by adjusting the raw UTC value (2023-10-15T07:30:00Z) to the user’s time zone (UTC-8) according to the column’s User Local behavior. If this server-formatted value is incorrect based on the expected adjustment rules, then the issue is originating on the server side. However, if this server-formatted value is correct, but the app is displaying something different, it strongly suggests a client-side rendering or calculation problem within the Power App itself.

Investigate Unexpected Server Values¶

If your investigation reveals that the raw UTC value stored on the server is incorrect, or the server-formatted value is wrong, you need to investigate the server-side processes that might be affecting the data. Several factors can lead to unexpected values being saved or formatted incorrectly on the server.

Firstly, double-check the time zone adjustment behavior and format configuration for the specific date and time column in Dataverse. An incorrect setting here is a common culprit. For instance, if you intended the value to be time-zone independent but set it to User Local, the server will store the UTC value, but the formatted value it provides will be adjusted, which might not be what you intended. Ensure the behavior setting aligns with how the data should be interpreted relative to time zones.

Secondly, server-side automation can modify data. Business rules configured in Dataverse can automatically set field values, trigger calculations, or enforce validations based on conditions. Workflows (both real-time and background) can also update record fields programmatically. These automations execute on the server. If a business rule or workflow is incorrectly configured, it could be overwriting or modifying the date and time value before or after it is saved, leading to the unexpected server value. Reviewing these automation processes associated with the table and the specific date/time field is critical.

Thirdly, while client scripts (JavaScript) primarily run in model-driven apps on the user’s browser, they can also influence the value sent to the server. A client script might manipulate the date or time value on the form before the user saves the record. Although the final save operation happens on the server, the value being sent to the server could be altered client-side due to faulty script logic, resulting in an incorrect UTC value being stored. Examining any client scripts attached to the form or the field is necessary if server values are unexpected.

Determine if it’s a Customization Issue or Product Issue¶

Unexpected behavior in Power Apps, including date and time issues, can often be traced back to customizations implemented within the application or its underlying Dataverse environment. Customizations can range from simple field configurations to complex client scripts, business rules, plugins, or custom controls. It’s essential to distinguish whether the problem is caused by one of these custom additions or if it’s a potential issue within the core Power Apps or Dataverse product itself. Ruling out customizations is a standard troubleshooting practice.

Disable Custom Scripts¶

Custom client-side scripts (JavaScript) are a frequent source of unexpected behavior in model-driven apps. They can interact with form fields, modify data before saving, or influence how data is displayed. If you suspect a script is interfering with date and time values, try temporarily disabling all custom scripts on the form or for the specific table. You can usually do this in the form designer by removing event handlers or by adjusting settings in the solution explorer. If disabling the scripts resolves the date and time issue, you’ve identified the source, and you can then focus on debugging the script code.

Test with a New Column or App¶

A highly effective method to determine if an issue is caused by existing configurations or customizations is to introduce a known working component. Creating a brand new date and time column in Dataverse with the desired behavior (e.g., User Local, Date and Time) and adding it to a form is a quick way to test. Ideally, test this new column on a different, less complex table or even in a separate, minimal test app if possible, to reduce the influence of other customizations.

If the new column behaves correctly when displaying and saving date/time values, it strongly indicates that the problem lies with the original column’s configuration, associated business rules, workflows, client scripts, or other customizations specifically affecting that original column or its table. You can then compare the configurations and associated logic of the new, working column with the problematic one to pinpoint the difference. This comparison should include field properties, form properties, business rules, and any related client scripts or plugins.

If, however, the new column exhibits the exact same date and time problem as the original column, even with minimal configuration and on a clean form or test app, it increases the likelihood that the issue might be a bug or limitation within the core Power Apps or Dataverse product itself. In such cases, documenting your steps and the observed behavior is crucial. You might consider creating a simple, “vanilla” repro model-driven app – an app with minimal components that strictly demonstrates the problem – to help isolate the issue for reporting.

If you conclude that it is a product issue, the appropriate next step is to file a support request through the official Power Platform admin center or your organization’s designated support channel. Providing clear steps to reproduce the issue and details about your environment (versions, configurations) will significantly help the support team investigate and resolve the problem.

Try a Different Time Zone¶

Time zone and daylight saving time adjustments are central to many date and time problems. Manipulating the time zone settings that affect the user viewing the data can provide valuable insights into whether these adjustments are the source of the unexpected values. There are two primary time zone settings that influence how dates and times are displayed to a user in model-driven apps:

1. User’s Personal Options Time Zone: This setting is specific to each user within their Power Apps/Dynamics 365 user profile. It determines the time zone used by the application when displaying or interpreting date and time values configured with the User Local behavior. Users can usually find and modify this setting within their personal settings or options menu in the app.
2. System Time Zone: This is the time zone set at the operating system level of the user’s device (Windows, macOS, iOS, Android). While the User Local behavior primarily uses the personal options time zone, the system time zone can sometimes influence client-side scripts, browser behavior, or other factors that might interact with date/time display or input.

Trying different combinations of these settings can help narrow down the problem. Some useful scenarios to test include:

• Matching Personal and System Time Zones: Ensure both settings are set to the same, standard time zone (e.g., UTC-8 Pacific Time). See if the issue persists or is resolved when these settings are aligned.
• Using UTC Time Zone: Change both the user’s personal options time zone and the system time zone to UTC (Coordinated Universal Time). Since Dataverse stores values in UTC, viewing data in UTC might reveal whether the issue occurs before any time zone adjustments are applied. If the value is correct in UTC but wrong in another time zone, the adjustment process is suspect.
• Using a Time Zone with the Same Offset but No Daylight Saving: Find a time zone that has the same standard offset as your user’s time zone but does not observe daylight saving time changes (e.g., UTC-5 could be tested against both Eastern Time and non-DST zones like Colombia or Peru depending on the time of year). If the problem specifically manifests during daylight saving transition periods or only in DST-observing zones, this test can help confirm that DST logic is involved.

During this testing, if a value displayed as “Date only” is off by a day, temporarily changing the column’s format to include the time component can be extremely helpful. This allows you to see the precise time after the time zone adjustment has been applied. Often, a “Date only” value showing the wrong date is because the adjusted time falls just before or after midnight in the user’s time zone (e.g., a UTC date that translates to 11:00 PM the previous day or 1:00 AM the next day in the user’s local time). Temporarily changing the format can be done in the column properties via the Power Apps portal or solution explorer.

Don’t Use 2-Digit Years¶

While seemingly a minor formatting detail, using 2-digit years when entering or displaying dates is strongly discouraged and can lead to significant confusion and potential issues. The ambiguity of a 2-digit year is its primary problem. For example, “40” could represent 1940, 2040, 2140, or even other centuries depending on the system’s interpretation rules. These interpretation rules can vary across different systems, browsers, or software versions and are subject to change over time (e.g., the “Year 2000” or Y2K issue was a large-scale example of problems caused by 2-digit year assumptions).

When troubleshooting date issues, especially those involving calculations, comparisons, or data migrations across systems, relying on 2-digit years makes it incredibly difficult to be certain of the intended date. It obscures the full context of the year, making it hard to diagnose why a date might be interpreted incorrectly or why calculations involving dates from different centuries could fail.

Furthermore, when troubleshooting, having the complete date and time information readily available is vital. Using a format that includes only two digits for the year adds an unnecessary layer of uncertainty. For these reasons, it is highly recommended to consistently use 4-digit years (e.g., 2023 instead of 23) for all date inputs, displays, and data storage.

If your application or data source currently uses 2-digit years, resolving the date/time problems permanently will likely require transitioning to a 4-digit year format. However, even as a temporary measure for troubleshooting purposes, changing the relevant fields or system settings to display and accept 4-digit years can significantly help in diagnosing the root cause of a date discrepancy. It removes the ambiguity and ensures you are looking at the full date intended.

Additional Troubleshooting Tips and Context¶

Beyond the core steps of checking server values, client formatting, and customizations, several other aspects are worth considering when tackling persistent date and time issues in Power Apps.

Understanding Date Only Behavior¶

The ‘Date only’ behavior for a column in Dataverse is unique. It stores only the date part (year, month, day) and discards any time information provided during input. Although internally it might store this date value relative to UTC midnight, it is generally treated as time-zone independent for display purposes. This means a date-only value entered as ‘October 15, 2023’ will typically show as ‘October 15, 2023’ to users regardless of their time zone. Issues with ‘Date only’ fields often arise if a process with a time component is incorrectly used to populate them, leading to the wrong date being stored if the time component crosses a UTC midnight boundary.

Time Functions in Canvas Apps¶

While this guide focuses heavily on model-driven apps and Dataverse behavior, Canvas apps also interact with Dataverse date/time values. Canvas apps have their own functions like Now() which returns the current date and time in the user’s local time zone, and UTCNow() which returns the current date and time in UTC. When patching data to Dataverse, ensure you are sending the value in the expected format, often UTC, or using functions that handle the conversion correctly. Explicitly managing time zones with functions like TimeZone or adjusting values manually might be necessary in complex Canvas app scenarios interacting with Dataverse.

Logging and Monitoring¶

Implementing logging or tracing within client scripts, plugins, or workflows can provide detailed insights into the exact date and time values being processed at different stages. Log the value of the date/time field before and after modifications, include the user’s time zone, and note whether daylight saving time is active. This detailed trail can help pinpoint precisely where and when the value becomes incorrect.

Potential Third-Party Integrations¶

If your Power App integrates with external systems (via connectors, APIs, etc.) that also handle date and time data, investigate how those systems manage time zones and formats. Inconsistent handling between Power Apps/Dataverse and integrated systems is a frequent cause of synchronization errors and incorrect data. Ensure that date/time values exchanged between systems are correctly converted and interpreted according to the expectations of each platform, often standardizing on UTC for data transfer.

Environment Specifics¶

Consider if the issue is specific to a particular environment (e.g., Development, Test, Production). Differences in environment settings, deployed solutions, or data might be contributing factors. Comparing the behavior in a problematic environment with a working one can help isolate the cause.

Here’s a simplified diagram illustrating the data flow and potential points of time zone adjustment:

mermaid graph TD A[User Input in App] --> B(Client-side Script/Logic) B --> C(App Framework Formatting) C --> D[Data Sent to Server (usually UTC)] D --> E(Server-side Business Rules/Workflows/Plugins) E --> F[Data Stored in Dataverse (always UTC)] F --> G{Data Retrieved by Server} G --> H(Server-side Time Zone Adjustment - for FormattedValue) H --> I[Formatted Value Sent to Client] G --> J[Raw UTC Value Sent to Client] I --> K{Client-side Display/Logic} J --> K K --> L[Value Displayed in App]

This diagram highlights that time zone adjustments can happen at multiple points. Issues can arise from incorrect logic in the client (B, K), server automation (E), incorrect server formatting (H), or simply misinterpreting the raw UTC value (J) without applying the correct time zone logic client-side (K).

Investigating date and time issues in Power Apps requires a systematic approach, starting from the source of truth (the server’s UTC value) and working outwards through server-side adjustments, client-side logic, and user/system settings. By carefully examining each layer and systematically ruling out common causes like configuration errors and customizations, you can effectively diagnose and resolve these often-complex problems.

If you’ve encountered stubborn date and time issues or found a particularly effective troubleshooting technique not mentioned here, please share your experiences! Your insights can help others in the community tackle similar challenges.