User-Local behavior with Date-Only format… what’s that for?

I’ll be absolutely honest – I have no idea what the answer is to the question above. Except that this combination of settings might be a legacy of the older versions of Dynamics CRM?

However, if I were to make a suggestion here, I’d say don’t use that combination. Since it may lead to confusing results.

But first things first –  here is what I’m talking about:

All those settings are described in the docs:

https://docs.microsoft.com/en-us/dynamics365/customerengagement/on-premises/customize/behavior-format-date-time-field

What remains unclear after looking at the docs is what’s going to be the time portion of the date and time field when it’s configured as per the screenshot above?

That’s easy to test. Here is what I have in the model-driven UI:

And here is what I see when querying that record through Web API:

I’m in EST, so 5 hours is what my timezone offset is. Which means the time portion there represents 00:00:00 in my timezone, so Jan 11 is just starting.

The tricky part is that, since the field is timezone-enabled, looking at the same value from another timezone might yield somewhat strange results.

If I were in GMT-6, I’d see that same value as Jan 10:

And, if I were closer to the UTC, I’d see that as Jan 11:

What’s happening there is that a user in any timezone that’s farther from UTC than my timezone will see the date I entered less one day.

Question is: why is it moving in that direction and not in the other, and why is it moving at all? And, then, how do we account for those movements properly when migrating data or even when typing in the date manually so that users in different timezones could, actulally, see what they need to see?

Unless there is a good example of where this helps, the actual answer seems to be: don’t use that combination of settings. Instead, opt for one of the other behaviors:

Date Only behavior will ensure that the date is stored as is on the server.And the time? It’ll be set to 12:00 AM. But, since it’ll be stored and presented as the same date and time in all timezones (12 AM on Jan 11), that’s not going to cause confusion.

Timezone-independent behavior might be another good option here. It’s, actually, not quite clear what’s the difference between “Date Only” behavior and “Timezone independent” with “Date only” format(you might also want to see what Scott Durow had to say on this topic), but both should yield predictable results.

Now this is how it looks in the classic designer. And, in the maker portal, things are somewhat different, since there are two different data type there:

But, if I created a “Date Only” field in the maker portal (with “User Local” behavior), here is how that field would look like in the classic designer:

In other words, it seems those two data types in the maker portal correspond to the “Format” in the classic designer.

And, so, what I wrote about “User Local “/ “Date Only” in above is also applicable to the “Date Only” type with “User Local” behavior in the maker portal. It seems that combination should be avoided, unless, of course, you have a good example of why it should not?