Another Date column, and that’s yet another kaboom

It happens every now and then that I have to re-create a columns across multiple environments, all because of the data type change. Sometimes, there are good reasons for that, and, sometimes, all I can do is kick myself for not thinking it through from the beginning; since, of course, changing data type for a a field that’s being used in various plugins/flows/reports is not a small feat.

And another thing I can do in such cases is write up a blog post – it’s sort of a “lessons learned” one.

If you prefer visuals, let’s start with this quick diagram – there is a nice kaboom right at the bottom:

You see, I actually wrote about date formats in Dataverse before:

https://www.itaintboring.com/dynamics-crm/user-local-behavior-with-date-only-format-whats-that-for/

Wait, I did it at least twice:

https://www.itaintboring.com/dynamics-crm/dates-in-dynamics-timezone-independent-vs-user-local/

And, yet, here we go – there is another kaboom.

Here is the problem with timezone independent date only columns:

• If you had such a column
• And if you set a value there from your plugin
• You’d usually use something like DateTime.UtcNow to set the date in C# (since you are supposed to be using UTC dates)
• However, timezone independent columns don’t care about whether the date is in UTC or not – it’s just the “date” that matter
• And, of course, if you are in EST, and if it’s 8 PM, then, when using DateTime.UtcNow, you’ll get “tomorrow” is your date. When you were probably expecting to see “today”

Problem is, this is all happening in the plugin, so you could, of course, use DateTime.Now, but it might be in the wrong timezone, too.

And this is all while timezone-independent behavior works nicely when column value is set directly on the client, since, on the client side, users will be setting the date consciously, so they’ll see what date they are using (unlike in the plugin, where date portion of UtcNow can be different from the user’s date because of time zone adjustments).

So, what should I do?

In my case, “User Local” behavior might, actually, work better in this scenario. The date is set automatically, so the only date I can rely on in the plugin is UtcNow, and, if I used “user local” behavior, that date would be adjusted to the user’s timezone when it’s displayed to the user. Which, in this case, is exactly what I need.

Of course I’d need to re-create that field now, which is going to be a pain in the… yep… but, well, off I go to work on that.