Introduction to Behaviours of Date and Time Fields in Dynamics 365

Satyvir Jasra, 17 November 2017

In Microsoft Dynamics 365, the “Date and Time” data type is used quite often. Based on the requirements, we have the options to choose the format between “Date Only” and “Date and Time”. But what matters the most is the accuracy of information being generated from the data, and this has been an issue in old versions of Dynamics CRMs.

For example, the “Date of Birth” field is used commonly in many organisations with the “Date Only” format, and some organisations use the same instance of Dynamics CRM in different time zones.  If a user enters 21-2-2017 in the “Date of Birth” field for a record from their CRM account with time zone of Auckland (GMT +12:00), then if the same record is being viewed with a different time zone such as Tokyo (GMT +9:00), it would display 20-2-2017 (one day behind).

This is because when the record was saved by the first user, its time element had the value set to 12:00 AM, and when the record is being viewed in Japanese time zone, the time is converted to 20-2-2017 8:00 PM. Therefore, the value is shown as 20-2-17.

Fortunately, in Dynamics 365 we can select the behaviour for Date Time fields. In this blog, I will walk through the differences between these behaviours.

User Local

The field values are stored in UTC time zone. However, the values being displayed to the user depends upon the time zone selected in user’s Dynamics 365 application. For example, I created a custom field called “Interview On” of “Data and Time” data type for the Contact entity. Following were the options selected in the “Type” section.

Once saved, I added the field onto the Contact main form. Then a new record was created by a user in New Zealand and a value was selected for the “Interview On” field.

After the changes were made, another user from Japan opened the same record, but would see a different value than the one stored earlier.

Even though the “Interview On” value in the database for this record hasn’t changed at all, the time being displayed in the CRM UI is different. This is because the value displayed to the user depends on their time zone.

Date Only

The field value doesn’t display any time, but only date. In the database, the time portion of the value stored is always 12:00 AM. The advantage of using this behaviour is that date value is displayed the same across all time zones. This behaviour is useful for fields such as “Date of Birth” because no time conversion will be done, and accurate information will be presented to the user every time.

I created a custom field called “Date of Birth” for a custom entity called “Pet”, with following options selected in “Type" section.

Once saved, I added the field onto the contact main form. Then a user from New Zealand selected a date of birth for one of the Contact records.

When the same record was opened by another user in Japan and date values were being displayed the same for the “Date of Birth” field.

Time-Zone Independent

The last behaviour type is “Time-Zone Independent”. When fields with format of “Date and Time” are set with behaviour “Time-Zone Independent”, the values are displayed the same across all the time zones. For example, I modified the behaviour of the field I recently created “Interview On”. I changed the behaviour to “Time-Zone Independent”. Following are the values that were set in “Type” section.

Note: Once the behaviour is set to “Time-Zone Independent”, it cannot be changed.

Once the changes were saved, user from New Zealand created a new Contact record and selected a value for “Interview On” field.

Then the record was reopened by another user in Japan. However, the values displayed in field “Interview On” was still the same for this user too.

Conclusions

There are a few things we must keep in mind. Out of the box field’s behaviour can be set to “Date Only” from “User Local”, but this cannot be done for all out of the box fields. Such as, “Original Start Date” field for Appointment entity is a field of type “Data and Time” and has behaviour set to “User Local”, and this cannot be changed. Also for a custom field, we can change the behaviour from “User Local” to “Time-Zone Independent” or “Date Only”.

Having the option to select either one of these behaviours saves us lots of additional coding time. For example, one of our clients had users from different time zones who were using same instance of CRM 2011. They used a field of format “Date Only”. Since data was being viewed in two different time zones, many records were displaying incorrect date in one of the time zones. There was no option to change the behaviour.  To come across this issue a lot of coding was required to update existing records, and automatically update future records.