Xamarin.forms: Bound DateTimes Display in en-US Format Not Local Format

I'm glad this is finally being looked at. It was logged on 8th of September 2017. It was originally reproduced by a Xamarin person the following day. This affects all Xamarin Forms users outside the USA, and Xamarin Forms users with non USA customers.

@rmarinho #2434 might be a dupe of this, and it might not. Either way, we need to get this fixed as it's quite a wide-spread issue. I'm happy to submit a PR if someone can give a little direction on where to tackle it.

just ringing the bell again on this issue, it's something that we're fighting with on a daily basis in a multi-lingual app. It's ready for work, and there are folks willing to help and submit PR's but we're still waiting for direction on how you'd like it solved.

I'm seeing a similar problem when applying a StringFormat to an Entry - see my detailed description on the Xamarin.Forms forum here. It's not related to Cultures, but _is_ related to how the Entry copes with formatting.

I think my problem is subtly different to the one described in this issue - but related. Is it worth me adding a new issue, or add more details here?

It seems like this bug has been around for a long time. I think that the support of multiple languages is an essential function of many apps. Currently you need some workarounds to accomplish this. I like to use Xamarin.Forms and it would be great if this bug will be fixed soon.

Thank you Xamarin Team for your great work!

Best regards

I have updated the repo address in case anyone was having trouble recreating the problem.

I think that the support of multiple languages is an essential function of many apps.

Agreed! If you'll look at the PR we opened to make this better (#3700), you'll see that we're struggling with how to do this in the best way possible that avoids breaking a large number of apps. We're open to suggestions! Thanks!

@samhouts

My money would be on implementing the Language property so as to opt in to a given language. Then, binding would be based on the Language property if it is set. It means that one line of code could switch the app over to the user's existing regional settings, but not necessarily change any existing functionality in existing apps. That's the way it's done on other XAML platforms. My guess is that those platforms had a similar issue to deal with and using that pattern would make Xamarin.Forms more compatible with those technologies.

I think that the support of multiple languages is an essential function of many apps.

Agreed! If you'll look at the PR we opened to make this better (#3700), you'll see that we're struggling with how to do this in the best way possible that avoids breaking a large number of apps. We're open to suggestions! Thanks!

My 0.2$ is that there is in .NET already a functionality designed to handle formatting and parsing: CultureInfo.CurrentCulture

If you from code format DateTime to a string with DateTime.Now.ToString() it will automatically use CultureInfo.CurrentCulture to format it. Same with parsing a string into a DateTime with DateTime.Parse - CurrentCulture is used.
Why shouldn't a Binding conversion (formatting) of DateTime -> string yield same result as when you do it in your ViewModel? The average developer is surprised and perplexed when they return different results. And do a simple google search to see how many variations and solutions there are as workarounds for this behavior, which could easily been handled by the framework.

Right now it is a mess where on-screen keyboards uses device setting for region, but .NET code parsing/formatting strings are using display language/culture. In the case of English UI and Swedish region you are typing numbers with a "," (comma) as decimal separator, and .NET tries to parse it using "." (dot) as decimal separator.

To tie up loose ends, Xamarin Forms should create a custom CultureInfo based on the settings on each platform/device (e.g. on iOS using Region settings), and assign as default to CultureInfo.CurrentCulture, so we, each and every developer, don't have to try and do it.

As a WPF developer you were stumped when binding doesn't adhere to what I've described above (and I consider it a bug) but it is easy to solve for WPF with
this.Language = XmlLanguage.GetLanguage(CultureInfo.CurrentCulture.IetfLanguageTag);.

Don't get me started with UWP, in which they seem to have forgotten that people actually want to have region/formatting different from you display language (like a large portion of the world wants) .

I just came across the same issue when binding an entry to a numeric property. It is even worse that the behaviour is different between types:

CurrentCulture = de-de

Binding from model to UI:
Binding a decimal property results in "10.41" (Current culture is not respected)
Binding a float property results in "10,41"
Binding a double property results in "10.41" (Current culture is not respected)

,i.e. only float properties are binded with the correct culture

Binding from UI to model:
only "." is recognized as valid separator regardless the datatype and the culture.

As a first step, please at least unify the behaviour for all datatypes.
as a second step please add a working solution for developers to bind numeric values correctly according the current culture and make on-screen numeric keyboards to be in sync with the current culture...

How can a framework get to this point, v4.4, and still get decimals working only for en-US?
I'm also having this problem and i have to work with string to decimal and decimal to string with all my decimal properties.....

Any news on this?

Issue still reproducable in the latest Xamarin.Forms Version.
Until now a solution is to create a IValueConverter to handle this.

Any info when this will be fixed?

Binding a DateTime to a Label which expects a string should be a type error, unless the user explicitly provides a function.

This issue surfaced when migrating from Xamarin.Forms 3.6.0.344457 to 4.4.0.991757.

In our case, we have a custom Entry, where we replace comma with a dot, so that when the user clicks comma on the soft keyboard, it would get replaced by a dot.

Weird solution, I know, but it used to work in 3.6.0.344457, but it doesn't in 4.4.0.99175. What has changed? Looking at the issue history, I can see some work was done in v3.6.0. It seems like it's a regression bug.

This issue doesn't seem to have had any activity in a long time. We're working on prioritizing issues and resolving them as quickly as we can. To help us get through the list, we would appreciate an update from you to let us know if this is still affecting you on the latest version of Xamarin.Forms, since it's possible that we may have resolved this as part of another related or duplicate issue. If we don't see any new activity on this issue in the next 30 days, we'll evaluate whether this issue should be closed. Thank you!

Yes it is still affecting the latest 4.8 version.