UUI: getValue() of Date field not returning Date object
Describe the bug
In XrmQuery we translate Date values to the expected Filter string by checking
if (v instanceof Date) return encodeSpecialCharacters(v.toISOString());
At least in UUI, getValue on Date fields does not actually return a Date object, even though it has the toISOString function (and behaves like a date)

To Reproduce Steps to reproduce the behavior:
- Go to a form containing a Date field
- Try to send XrmQuery request Filtering on the field
- Notice that the Filter is serialized using ToString() instead of toISOString()
Expected behavior The Date field is handled as a Date when serialized
Environment
- CRM/D365/CDS version: 9.1.0.10740
- Tool version: 4.3.13
It works fine for me both in UUI and Web UI:
This is from a 9.1.0.10740 instance. Same behavior in Chrome and Edge.
Can you look closer at which browser/environments/date field settings result in this not working for you (and possibly arguing why this has something to do with XrmDefinitelyTyped)?
It is very strange.
It appears that when requesting getValue for an attribute, the context of the request has an influence on the type of the object.
If I use Xrm.Page.getAttribute in the top-level context, i get the expected behaviour, but when requesting from a deeper context, where the client script is run, the behaviour is wrong.
Seems to be a bug in CRM
Have you resolved whether this is intended behavior or a bug in D365?
The documentation states that it should be a Date. And since the top-level context returns a Date, I think it is safe to assume that is the intended behaviour. In addition to Xrm.Page.getAttribute("new_myattribute").getValue() instanceof Date returning false when new_myattribute is a date-only column, Xrm.Page.getAttribute("new_myattribute").getValue() instanceof Object also returns false despite typeof Xrm.Page.getAttribute("new_myattribute").getValue() returning object.
This being the case I don't think we should make changes to XrmQuery to handle non-Date objects. Although it could resolve this issue and avoid manually handling it in every TS file that wants to query using a date-only field's value. But it would just be a workaround for what I expect is a wrong return type.