Improving SetProperty for DatePicker control to be consistent across every timezone

[NavneetThekkumpat]

• Currently with the SetProperty() function when used to set Date value no timezone is specified and hence Date.parse() converts the date to unix timestamp for the local time.
• This could cause discrepancy when the value of the DatePicker control is fetched, where in the value is in UTC . So in first step in a different timezone like IST, if the user sets the date to value lets say Date(2029/11/05). Here in this step the getProperty() will get the value in UTC that is 2029/11/04.
  Example tests that passes.

 SetProperty(DatePicker1.SelectedDate, Date(2029, 11, 05));
 Assert(DatePicker1.SelectedDate = Date(2029, 11, **04**), "Validate date was changed");

• To avoid this discrepancy, we need to make sure that the SetProperty() sets date time value in UTC. Hence the datepicker control date value is consistent with the UTC format, the below test runs successful.

 SetProperty(DatePicker1.SelectedDate, Date(2029, 11, 05));
 Assert(DatePicker1.SelectedDate = Date(2029, 11, 05), "Validate date was changed");

• The changes here assures if the user setProperty() to set date value for datepicker and tries to Assert the value, then it is consistent, since its always saved in the UTC format.

References https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Date/parse

Checklist

• The code change is covered by unit tests. I have added tests that prove my fix is effective or that my feature works
• I have performed end-to-end test locally.
• New and existing unit tests pass locally with my changes
• I have commented my code, particularly in hard-to-understand areas
• My changes generate no new warnings
• I used clear names for everything
• I have performed a self-review of my own code

[jt000]

Should this be handled in the JSSDK?

[NavneetThekkumpat]

We could potentially change it there too. I thought since we have an option to pass the right value here much earlier in the lifecycle(we have separate handlers for each value type setProperty , i.e date, record, table etc). Are you concerned about how secure this string is ?

[jt000]

I'm not worried about the security since there isn't any new user-provided strings. I'm just curious about the trade-offs between forcing a user to update the Test Engine versus having to republish their app to get the fix. Just wanting to make sure you've considered the implications of each of these options & that this is the correct one... (not sure if there was an Analyze on this, if so, I apologize if this was discussed already...)

[NavneetThekkumpat]

Sure, good point. Considering the easiest option for users. Here since the changes are in the TestEngine code and not in jssdk, user would have to just get the latest TE.

[jt000]

Are there other places where this might be called other than the DatePicker which might expect the time to be included?

[NavneetThekkumpat]

No, this is specific and only to SetProperty with date value.

[jt000]

Sorry, I don't think I was clear. Might it be possible that someone is calling SetProperty on a control that isn't a DatePicker? For example, is there a control which might be expecting the Time to be included & not replaced with 0000Z?

[NavneetThekkumpat]

ah interesting. With the known scenarios so far we do have such properties that takes in date value(for setProperty) other than date picker control.
If such a scenario exist or is possible I would say it would be ideal to make these changes in the jssdk and make this condition specific to datepicker control.

[github-actions]

Package	Line Rate	Branch Rate	Complexity	Health
Microsoft.PowerApps.TestEngine	91%	87%	982	✔
Summary	91% (2543 / 2794)	87% (598 / 684)	982	✔

Minimum allowed line rate is 85%