In this article, we deep dive into the Microsoft Dynamics 365 Customer Engagement Date and Time field type, as well as explore the implications of this field type on SQL Server Reporting Services (SSRS) reports depending on the behavior and format selected. We demonstrate how to make SSRS reports to display Date and Time fields in the user’s time zone. Also, we look at how the different behaviors and formats of the Date and Time field type are stored in the SQL database. The included use case provides a real world scenario of where the information in this article came in handy.
Use Case
Inspiration
Recently on a client engagement, a bug was raised on a couple of SSRS reports I had built a few months ago. A date field on the reports was displaying the next day i.e. if a record was approved yesterday, the report was showing that it was approved today in some cases. Looking at the records from the Dynamics 365 user interface, i.e. views, Advanced Find and forms, the field was displaying the correct date despite the SSRS reports were showing that same date as the next day. This behavior was only observed on some of the records created by the clients.
I thought of sharing the problem solving approach and tools I used to resolve this bug with the hope the it may help another Microsoft Dynamics 365 software developer in the future.
What was going on
The field in question it is a Date and Time field but the reports are configured to show the date part of the field only, as per the requirements. After investigations, it turned out that the SSRS reports were consuming a Date and Time field type (Behavior: User Local. Format: Date and Time), without translating it into the user’s time zone. Therefore, if a user approved a record between 8pm and Mid-night EST, the date of approval would show up on the SSRS report as the following day. This is because if a Date and Time field type’s behavior is set to User Local, the actual data is store in UTC time but translated to the user’s time zone when displayed to the user in the Dynamics 365 user interface. Unlike the Dynamics 365 user interface, SSRS reports do not automatically provide the translation to the user’s time zone but is can be implemented as shown in the SSRS Reports section below. Therefore, the source of the discrepancy between the date seen by users in Dynamics 365 user and what was being shown in the report lies in the fact that the Dynamics 365 user interface was translating the UTC date into the user’s local time while the report was showing the date as it was recorded in the SQL database. As the client is based in the EST, the bug could only be replicated, under the same conditions, between 8pm and Mid-night EST, when EST and UTC exist on two calendar dates.
Some of the client’s employees was creating the data between 8pm and Mid-night EST. As the field’s behavior is set to User Local, in the four hours time window (8pm to Mid-night EST), UTC and EST are on two different dates, and records approved in period will stored on the following day in UTC, which the database time for User Local behavior fields.
The Tools to Debug the Problem
View the Behavior and Format of Date and Time FIelds
Open the Date and Time field in the Dynamics 365 solution and see how it is saved:
Date and Time Fields: Behavior and Format
The table below shows the different behaviors and formats of Date and Time fields in Dynamics 365, and well as their implications.
Behavior | Format | Changing field’s behavior |
User Local Note: This is the behavior of all date and time fields in the previous releases. – The field values are displayed in the current user’s local time. – In Web services (SDK), these values are returned using a common UTC time zone format. | Date Only – or – Date and Time | In the user interface (UI), you can change certain out-of-the-box entity field’s behavior from the User Local to Date Only. For a list of entities and fields, see Changing the field behavior to Date Only on upgrade. You can change the custom entity field’s behavior from the User Local to Date Only or to Time-Zone Independent. Changing the field behavior affects the field values that are added or modified after the field behavior was changed. The existing field values remain in the database in the UTC time zone format. To change the behavior of the existing field values from UTC to Date Only, you may need a help of a developer to do it programmatically. More information: Convert behavior of existing date and time values in the database. Warning: Before changing the behavior of a date and time field, you should review all the dependencies of the field, such as business rules, workflows, calculated fields, or rollup fields, to ensure that there are no issues as a result of changing the behavior. After changing the behavior of a date and time field, you should open each business rule, workflow, calculated field, and rollup field dependent on the field that you changed, review the information, and save it, to ensure that the latest date and time field’s behavior and value are used. You can restrict modifying the field’s behavior, by setting the CanChangeDateTimeBehavior managed property to False. More information: Set managed property to change date and time behavior |
Date Only – The concept of a time zone isn’t applicable to this behavior. The field values are displayed without the time zone conversion. – The time portion of the value is always 12:00AM. – The date portion of the value is stored and retrieved as specified in the UI and Web services (SDK). | Date Only | The Date Only behavior can’t be changed to other behavior types, once it’s set. |
Time-Zone Independent – The concept of a time zone isn’t applicable to this behavior. The field values are displayed without the time zone conversion. – The date and time values are stored and retrieved as specified in the UI and Web services (SDK). | Date Only – or – Date and Time | The Time-Zone Independent behavior can’t be changed to other behavior types, once it’s set. |
.
Date and Time fields in Dynamics 365 User Interface vs. SQL Database
Dynamics 365 User Interface: Date and Time fields
Here are the different possible combinations of storing simple dates and time data in Dynamics 365 (on a classic interface form for the Contact entity):
SQL Database: Date and Time fields
In this section, we will look at how the date and time fields in the previous section are stored in the database. The date and time fields are on the Contact entity (i.e. ContactBase table in my Dynamics 365 SQL database). Querying for the specified columns in the table where the full name is ‘Peter Parker’:
SELECT TOP (10)
[FullName]
,[hos_uselocal_dateonly]
,[hos_uselocal_dateandtime]
,[hos_dateonly_dateonly]
,[hos_timezoneindependent_dateonly]
,[hos_timezoneindependent_dateandtime]
FROM [House_MSCRM].[dbo].[ContactBase]
WHERE FullName = 'Peter Parker'
See the results below:
From the database results above, it is worth noting:
- Behavior of User Local and Format of Date Only: these fields are always stored as 4am in my database in EST, which is 12am UTC.
- Behavior of User Local and Format of Date and Time: in my time zone, i.e. EST, these fields are always stored 4 hours ahead, i.e. UTC time, in the database. In contrast, in the user interface, this field always shows the data in my time zone.
- Behavior of Time Zone Independent and Format of Date and Time: stores the data in the database as inputted in the user interface and does not respect time zones.
SSRS Reports: Display Dates and Time in the user’s time zone
There are two ways to create SSRS Reports for Dynamics 365. You can create a report in Dynamics 365 using the Report Wizard, export it and add to your Report Server Project in Microsoft Visual Studio IDE, with the built-in fields and parameters, from Dynamics 365. Alternatively, you can take the opposite path of creating a blank Report Server Project in Microsoft Visual Studio IDE, connecting to Dynamics 365, and adding the built-in fields and parameters as needed. If you take the former approach, you will get the built-in fields and parameters in Visual Studio, similar to the image below:
To translate UTC date and time data, for User Local behavior, in the SQL database into the user’s time zone, you have to use the SSRS Report formula below, where “CRM_UserTimeZoneName” is a parameter and <SSRSDateAndTimeField> is name of your Date and Time field in SSRS:
=Microsoft.Crm.Reporting.RdlHelper.DateTimeUtility.ConvertUtcToLocalTime(
<SSRSDateAndTimeField>, Parameters!CRM_UserTimeZoneName.Value)
“CRM_UserTimeZoneName” is a parameter passed in from Dynamics 365, containing the user’s time zone. The function “Microsoft.Crm.Reporting.RdlHelper.DateTimeUtility.ConvertUtcToLocalTime” iconverts UTC time to the user’s time zone. Therefore, when the user runs the report, they will see the date and time data in their time zone, despite it is stored as UTC by default in the SQL database.
Here are some application examples, where “Fields!hos_uselocal_dateandtimeValue.Value” is the SSRS date and time field in Visual Studio:
- Display User Local Date and Time SSRS data field in the user’s time zone (showing both date and time data):
=Microsoft.Crm.Reporting.RdlHelper.DateTimeUtility.ConvertUtcToLocalTime(
Fields!hos_uselocal_dateandtimeValue.Value, Parameters!CRM_UserTimeZoneName.Value)
- Display User Local Date and Time SSRS data field in the user’s time zone (showing the date component only without the time component of the date, in the format dd/MM/yyyy):
=Format(CDate(Microsoft.Crm.Reporting.RdlHelper.DateTimeUtility.ConvertUtcToLocalTime(Fields!hos_uselocal_dateandtimeValue.Value,
Parameters!CRM_UserTimeZoneName.Value)), "dd/MM/yyyy")
Dynamics 365 Online: Accessing the contents of your SQL database
In Dynamics 365 Online, you do not have access to the SQL database that hosts your Dynamics 365 organization. However, Microsoft allows you to access the data in your SQL database by duplicating and syncing to Microsoft Azure. From Azure, you can connect to duplicated SQL database and be able to run the SQL script in this article. For more details duplicating and syncing your Dynamics 365 online SQL database to Microsoft Azure, see: Microsoft Dynamic 365 Data Export Service: Duplicating and Syncing SQL database in Azure