Dynamics 365 Marketing - TimeZone Independent DateTimes in C#

Adam Murchison, 17 September 2020

Working with DateTimes are often problematic and Microsoft have added some new functionality when working with them in Dynamics 365 Marketing that may cause issues. In this scenario, we’re retrieving a Time-Zone Independent date field and setting the retrieved value into a User Local date field. With the Time-Zone independent DateTime, it has a new field in Dynamics 365 for Marketing accompanied with it ‘Time Zone’ as seen below.

When the Time-Zone independent DateTime is retrieved in code (e.g. a plugin), it is retrieved exactly as it is displayed in the UI as shown above, unlike User Local Date Time fields which retrieve the UTC converted value. Our code still interprets this as a UTC DateTime, even though we know it’s actually already in our local time.

When you take this Time-Zone independent DateTime value and set it to a User Local Date Time field, the system will store the value directly as UTC without doing any time zone conversion, so if a user has their time zone settings as New Zealand Standard Time it will show the incorrect date time as the interface will +12 hours onto the date time again.

Important notes:

This occurs due to fields being ‘Time-Zone Independent’ but with Dynamics for Marketing there are additional TimeZone fields to help us with conversion.

When you’re setting a DateTime in C# in Dynamics, the DateTime in the database is stored as UTC so it’s recommended to set the value in UTC time, and if no DateTimeKind is given with the DateTime then the database will assume it already is in UTC.

Also, my personal settings are set to New Zealand Standard Time.

Working with DateTimes in Dynamics for Marketing:

You may notice that some DateTimes have a TimeZone associated with it on the form.

This is super important when you’re working with DateTimes in C# in something like a plugin. When you retrieve the DateTime, it will be retrieved as you see it displayed on the form with no Time Zone associated with it. This means if you retrieved the Start date value from Dynamics 365 Marketing in code, it will be ‘21/08/2020 5:56pm’ but if it was a standard User Local DateTime it would be retrieved in UTC (in this case -12 hours 21/08/2020 5:56am).

This is shown in the code below:

To get the actual UTC value so you can use it with other User Local Date Time fields, you can retrieve the Time Zone as seen on the form. This is done in the query below, notice the ‘bias’ column that is retrieved. The bias column is the Time Zone offset in minutes. As you can imagine, to set the DateTime retrieved (No timezone set but inferred to be GMT+12:00 in this example) to UTC you simply add the bias value onto the DateTime in minutes and this will provide the UTC value so you can use it with other User Local Date Time fields in Dynamics 365.

Note: the timeZoneCode variable is the int value of the picklist option from the ‘Time zone’ field with the red box around it on the form in the image above.

QueryExpression qe = new QueryExpression("timezonedefinition");
qe.ColumnSet = new ColumnSet("bias");
qe.Criteria.AddCondition("timezonecode", ConditionOperator.Equal, timeZoneCode);
EntityCollection ec = sdk.RetrieveMultiple(qe);

if (ec.Entities.Count > 0)
{
    int minutes = ec.Entities[0].Get<int>("bias");
    DateTime startDateTimeUtc = startDateTime.AddMinutes(minutes);
}

Summary:

DateTimes without a Time Zone associated with them can be a pain when working with them in code, especially if you’re missing Time Zone Independent fields with User Local fields. Luckily there is a way around it using timezonedefinition and using the bias to add minutes to the retrieved DateTimes value to convert it to UTC format.