PST2UTC cloud flow receives different datetime formats as input

Bug report from a user located in UTC, most likely in the UK.

The issue was that the person was not seeing any availability on their side. Upon a further investigation I found that there was in issue when running the `PST2UTC` cloud flow.

The error is due to the format of the date to convert. This was the input that is causing the flow to fail: `29/12/2022 09:00`.
By looking at previous runs, I discovered that the provided date will be formatted on the user's regional date format on their computer. So, for someone located in the US with the US regional format, the date will be passed into the flow like this: `12/29/2020 09:00 PM`.
Other variation of dates is `December 26, 2022 09:00 PM`, for someone located in Mexico with the mexican regional date format. Both formats will suceed, the only one failing is `dd/mm/yyyy hh:mm`.

My toughts on this is that the short format with only numbers is expected to always be `mm/dd/yyyy hh:mm`.

One possible solution for this is to manually format all of the dates when calling the flow, by adding the `Text()` function like this:
```
'TimeZone-PST2UTC'.Run(
Text(
Date(
Year(Today()),
Month(Today()),
Day(Today())
) + Time(
LookUp(
_eventSchedulesPacific,
ThisRecord.WeekDay = Weekday(Today())
).Time.Hour,
LookUp(
_eventSchedulesPacific,
ThisRecord.WeekDay = Weekday(Today())
).Time.Minute,
0
),
"mm/dd/yyyy hh:mm"
)
).date
```

Anyway, this issue could actually be solved as part of [#4390](https://github.com/Azure/azure-sdk-tools/issues/4390), so we can wait until that issue is completed to see if this bug is also fixed.

Start by reproducing the PST2UTC cloud flow with the reported dd/mm/yyyy input and compare it with the US and long-form inputs described here. Trace where the date is parsed or converted, and check issue #4390 before proceeding; done means the flow handles the reported regional formats without failing.

Written by the indexing model from the issue text.