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

[MelbourneDeveloper]

Description

When you display a bound DateTime on a control like Label, it will always display the DateTime in en-US format. For users outside the USA this is a problem.

Original bug report:
https://bugzilla.xamarin.com/show_bug.cgi?id=58635

Notes about other platforms
On Silverlight, UWP, and WPF all controls inherit from FrameworkElement and FrameworkElement has the "Language" property. This is what drives DateTime formatting on these platforms. On Silverlight and WPF there is a bug where the Language property does not default to the local Language. So, by default WPF, and Silverlight have the same bug as Xamarin Forms. But, this can be solved with one line of code:

        Language = XmlLanguage.GetLanguage(Thread.CurrentThread.CurrentCulture.Name);

Here is a WPF sample app that shows this:
https://www.dropbox.com/s/2qcacomtsjweb1o/DateTimeWPF.7z?dl=0

But, on UWP, the Language property correctly defaults to the machine's local language. So, DateTime conversion shows up correctly in UWP by default.

So, Xamarin Forms probably needs a Language property, and this Language property needs to default from the machine's regional settings.

Steps to Reproduce

1. Switch the culture of your device and Date format to en-AU (day/month/year)
2. Clone this repo: https://[email protected]/MelbourneDeveloper/xamarin-forms-scratch.git
3. Run the UWP, or Android sample, and click "Date Display"
4. Notice that the first date is displayed as "31/1/2000 12:00:00 AM" (This is manually converted from DateTime to string with ToString().
5. Notice that all other displayed dates which are converted using XF's core conversion code are displayed in en-US format as "01/31/2000 00:00:00"
6. I.e. ToString() is giving a different value to the displayed binding. The bug is that binding is not calling ToString() to convert from DateTime to string. It is doing something different and therefore not correctly formatting the date

Expected Behavior

When a DateTime is converted to a string in binding, it should be converted with a vanilla ToString() which will use the machine's local language settings.

Actual Behavior

DateTimes are converted to USA format strings regardless of the regional settings.

Basic Information

• Version with issue: 2.5.0.280555
• Platform Target Frameworks:
  
  
  
  • UWP: 16299
  
  
• Android Support Library Version:
• Nuget Packages:
• Affected Devices:

Reproduction Link

https://[email protected]/MelbourneDeveloper/xamarin-forms-scratch.git

[MelbourneDeveloper]

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.

[ChaseFlorell]

@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.

[ChaseFlorell]

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.

[ghost]

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?

[nicolaiw]

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

[MelbourneDeveloper]

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

[samhouts]

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!

[MelbourneDeveloper]

@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.

[marnilss]

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) .

[Alex-111]

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...

[fredericoregateiro]

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.....

[simader]

Any news on this?

[jonkas2211]

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

[Lebapp]

Any info when this will be fixed?

[charlesroddie]

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

[RedasP]

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.

[samhouts]

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!

[EmilAlipiev]

Yes it is still affecting the latest 4.8 version.