Skip to content
This repository has been archived by the owner on May 1, 2024. It is now read-only.

Bound DateTimes Display in en-US Format Not Local Format #2049

Open
MelbourneDeveloper opened this issue Mar 8, 2018 · 24 comments
Open

Bound DateTimes Display in en-US Format Not Local Format #2049

MelbourneDeveloper opened this issue Mar 8, 2018 · 24 comments
Labels
a/l10n e/9 🕘 9 i/high Completely doesn't work, crashes, or is unusably slow, has no obvious workaround; occurs less often in-progress This issue has an associated pull request that may resolve it! m/high impact ⬛ p/0 t/bug 🐛

Comments

@MelbourneDeveloper
Copy link

MelbourneDeveloper commented Mar 8, 2018

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://MelbourneDeveloper@bitbucket.org/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://MelbourneDeveloper@bitbucket.org/MelbourneDeveloper/xamarin-forms-scratch.git

@MelbourneDeveloper
Copy link
Author

MelbourneDeveloper commented Mar 14, 2018

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
Copy link

@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
Copy link

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
Copy link

ghost commented May 10, 2018

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?

@samhouts samhouts added this to To do in Sprint 138 Jul 2, 2018
@samhouts samhouts added this to To do in Sprint 139 via automation Jul 23, 2018
@samhouts samhouts added i/critical i/high Completely doesn't work, crashes, or is unusably slow, has no obvious workaround; occurs less often m/high impact ⬛ e/6 🕕 6 and removed i/critical labels Jul 23, 2018
@samhouts samhouts removed this from To do in Sprint 139 Jul 24, 2018
@samhouts samhouts added this to To do in Sprint 140 Aug 11, 2018
@samhouts samhouts added this to To do in Sprint 141 Sep 1, 2018
@samhouts samhouts added this to To do in Sprint 141 Sep 1, 2018
@samhouts samhouts added this to In Review in v3.6.0 Sep 4, 2018
@samhouts samhouts moved this from In Review to In Progress in v3.6.0 Sep 4, 2018
@samhouts samhouts moved this from To do to In progress in Sprint 141 Sep 4, 2018
@samhouts samhouts removed this from Ready For Work in Triage Sep 4, 2018
@samhouts samhouts moved this from In Progress to In Review in v3.6.0 Sep 6, 2018
@samhouts samhouts moved this from In progress to Ready for Review (PRs) in Sprint 141 Sep 6, 2018
@samhouts samhouts moved this from In Review to In Progress in v3.6.0 Sep 6, 2018
@samhouts samhouts moved this from Ready for Review (PRs) to Ready for Review (Issues) in Sprint 141 Sep 6, 2018
@marnilss
Copy link

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
Copy link

Alex-111 commented Aug 7, 2019

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
Copy link

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
Copy link

simader commented Feb 13, 2020

Any news on this?

@jonkas2211
Copy link
Contributor

jonkas2211 commented Feb 26, 2020

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

@Lebapp
Copy link

Lebapp commented Mar 8, 2020

Any info when this will be fixed?

@charlesroddie
Copy link

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

@RedasP
Copy link

RedasP commented Apr 3, 2020

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 samhouts added the in-progress This issue has an associated pull request that may resolve it! label Jun 20, 2020
@samhouts samhouts added this to In Progress in vCurrent (4.8.0) Jun 20, 2020
@samhouts samhouts removed this from In Progress in vCurrent (4.8.0) Jul 30, 2020
@samhouts samhouts added this to the 5.0.0 milestone Aug 13, 2020
@samhouts
Copy link
Member

samhouts commented Oct 1, 2020

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!

@samhouts samhouts added the s/needs-info ❓ A question has been asked that requires an answer before work can continue on this issue. label Oct 1, 2020
@samhouts samhouts added this to Needs Info in Triage Oct 1, 2020
@EmilAlipiev
Copy link
Contributor

Yes it is still affecting the latest 4.8 version.

@Redth Redth removed the s/needs-info ❓ A question has been asked that requires an answer before work can continue on this issue. label Oct 15, 2020
@Redth Redth moved this from Needs Info to New in Triage Oct 15, 2020
@Redth Redth moved this from New to Ready For Work in Triage Oct 15, 2020
@samhouts samhouts removed this from the 5.0.0 milestone Nov 2, 2020
@samhouts samhouts added this to To do in Other Ready For Work Nov 3, 2020
@samhouts samhouts removed this from Ready For Work in Triage Nov 3, 2020
@nixkuroi
Copy link

nixkuroi commented Jan 13, 2021

Having a similar issue when converting between a list to a comma separated string in Xamarin.Forms 5.0.0.1874

    public object Convert(object value, Type targetType, object parameter, System.Globalization.CultureInfo culture)
    {
        if (value is List<string> keywordList)
        {
            return String.Join(",", keywordList);
        }

        return null;

    }

    public object ConvertBack(object value, Type targetType, object parameter, System.Globalization.CultureInfo culture)
    {
        //throw new NotImplementedException();
       if (value is string kw)
        {
            if (kw.Contains(","))
            {
                return kw.Replace(" ","").Split(',').ToList();
            }
            else
            {
                return new List<string>() { kw };
            }
        }
        return null;
    }

I'm sure it can be worked around with converting it to a string when data is retrieved and then converting it back to a list on save, but that's not really the best use of time, and having to add hack properties is not great.

@CARP-Kaiser
Copy link

Just an update https://developercommunity.visualstudio.com/t/xamarin-forms-entry-does-not-accept-foreign-langua/449922 is still an issue in forms v5.0.0.1931. I have a commercial app out where I need this to work. Two weeks ago I was told I needed multilingual support and this is the last thing holding me up. Has anyone found a workaround while this is in progress?

@LeptronSoftware
Copy link

LeptronSoftware commented Jul 1, 2021

I have a Xamarin app whose primary user base will not be in the United States and this will be a noticeable bug for us. There is no workaround for UWP that I can find. Any updates?

@CARP-Kaiser
Copy link

@LeptronSoftware you can extend the control to actively replace the "." with a ",".

@ToolmakerSteve
Copy link

@samhouts - This current SO post - DatePicker not showing year from current culture Thai may be related to this issue.

@nagyist
Copy link

nagyist commented Dec 19, 2021

try the following workaround:
in your App.xaml.cs:
protected override async void OnInitialized()
{
// this solved the issue for me, at least for datetime format strings:
// get system culture for the app:
CultureInfo.DefaultThreadCurrentCulture = Thread.CurrentThread.CurrentCulture;
...
InitializeComponent();
...
}

HTH

@samhouts samhouts added the p/0 label Jan 6, 2023
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
a/l10n e/9 🕘 9 i/high Completely doesn't work, crashes, or is unusably slow, has no obvious workaround; occurs less often in-progress This issue has an associated pull request that may resolve it! m/high impact ⬛ p/0 t/bug 🐛
Projects
Sprint 138
  
To do
Sprint 140
  
To do
Sprint 141
  
Blocked
Development

Successfully merging a pull request may close this issue.