Datepicker does not work in Chrome based browsers outside USA

[DeadmanWNC]

We created a canvas app with a date picker control.

If users are in UK or Europe and they DO NOT use Internet Explorer the date stored back into Dataverse is wrong. Example they pick 3rd Aug from the Calendar, the date written to Dataverse is 8th March.

If the users are in UK or Europe and they use Internet Explorer the date stored back into Dataverse is Correct.

If the users are in USA and they use any browser, the date stored back into Dataverse is Correct.

The issue only shows after the app has been saved and published, preview mode works as expected.

We have tried :-

DateTimeZone.Local and DateTimeZone.UTC - same result

Older and new version of PowerApps - same result

3 hrs on phone to MSFT support - same result

Work-a-round suggestion is to build our own date picker control with 3 drop downs for each component of the date and piece it back together - Not a nice solution for users.

[RusselThomas]

Hi @DeadmanWNC ,

Based on the dates you mentioned, it seems something somewhere is swapping the month value with the day value - which typically means a regional setting conflict between the client and the destination.

This is sometimes most obvious with regions that use different list syntax in code - but in your case would just be because one uses dd/mm/yyyy and the other uses mm/dd/yyyy.  It might also not just be at the regional level, but the control level (i.e. the datepicker preference, as I'm not sure if this is hard-coded or inherited).

It's generally as confusing as anything trying to sort this out, as it's not always obvious when using dates that are interchangeable - like 1/1/2021 is the first of the first, whichever way you process it, but 1/2/2021 could be the first of the second, or the second of the first, depending on which way you process it - whereas 20/1/2021 can only be successfully processed in the format dd/mm/yyyy.  The problem might also only surface when converting a text input to a date as this is where they can get swapped around.

Depending on the source of the conflict, you either have to try use code to correct it, or ensure the client/server regionalisation difference is being catered for by the browser or local machine - and both can be tedious based on variable machine configs and group policies or trying to maintain a single user experience.

What we're looking for is the point of the conversion, so this may take a little troubleshooting to figure out, but it should be resolvable.  

I assume everyone using the same app and same dataverse table in the same instance (i.e. the cloud side of this equation is constant across geographies?)

The fact that it's fine in Studio but not fine when published might mean studio is enforcing local while the published app inherits browser settings.  Something you can try on Windows 10 on the UK/Europe machines - search for "Choose if wesbites can use your language list" and open the setting.  Set "Let websites provide locally relevant content...." to the opposite of what it currently is, then restart your browser and run your app to see if that makes a difference. 

The workaround suggested also implies that you can solve this with code, but I'm not sure why you have to build a whole new datepicker - you should be able to just adjust the output of the one you have so it's explicit and works for all regional scenarios...what you adjust it to just depends on how you're using it, whether in a Form or a Patch.   

Kind regards,

RT

[JR-BejeweledOne]

We have run into something similar that tends to indicate that it really is an issue with the browser or between the browser and the MS Cloud.     In testing some recent app functionality, we discovered that DateTime values are not displaying correctly based on the browser settings.    A date of 3/1/2021 does not convert and display as 1/3/2021 for those whose browser language and pc language settings are set to show DD/MM/YYYY rather than MM/DD/YYYY.    This is true even in SharePoint created and modified date columns.  Our official browser is Chrome, although many of us use the new Edge.   We tested with both and had people in different countries test and found the same results.    

All of the MS documentation on the subject indicates that the language settings of the computer and browser should be the controlling factor.