double.TryParse of "0,12" incorrectly returns true with result of 0.12.

[DonaldRich]

When executing the following the return value is true (parsing succeeded) and the number value becomes 0.12:

double.TryParse("0,12", NumberStyles.Number, CultureInfo.GetCultureInfo("en-US"), out number)

The input is not a valid US number since the comma proceeded by a zero and followed by only 2 digits. US numbers with a comma are only valid if the integer part is a 1 to 3 digits (but not a sequence of zero digits) followed by zero or more groups of 3 digits separated by commas.

VisualStudio 2015 Version 14.0.25431.01 Update 3
Microsoft .NET Framework
Version 4.7.02556
Build for x64 and .Net 4.5

Installed Version: Community

[ghost]

using System;
using System.Globalization;
class Program
{
    static void Main(string[] args)
    {
        Console.WriteLine(double.TryParse("0,12", NumberStyles.Number, CultureInfo.GetCultureInfo("en-US"), out double number));
        Console.WriteLine(number);
    }
}

Prints:

True
12

with net40, net45, net452, net46, net461, net47, netcoreapp2.0 and netcoreapp2.1.

How is it producing 0.12 on your system?

[nil4]

@DonaldRich do you see different results if you change CultureInfo.GetCultureInfo("en-US") to new CultureInfo("en-US", useUserOverride: false)?

[DonaldRich]

The bug is that it is not failing. As I wrote, "0,12" is not a valid number in the US. It would only produce 0.12 in a culture which uses periods (.) for the thousand separator and the comma as the decimal point. The proper behavior is for this call to return false.

…

On Fri, Apr 13, 2018 at 7:26 PM, kasper3 ***@***.***> wrote: using System;using System.Globalization;class Program { static void Main(string[] args) { Console.WriteLine(double.TryParse("0,12", NumberStyles.Number, CultureInfo.GetCultureInfo("en-US"), out double number)); Console.WriteLine(number); } } Prints: True 12 with net40, net45, net452, net46, net461, net47, netcoreapp2.0 and netcoreapp2.1. How is it producing 0.12 on your system? — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub <https://github.com/dotnet/corefx/issues/29059#issuecomment-381188838>, or mute the thread <https://github.com/notifications/unsubscribe-auth/ABuuDa4w-dKUZ8e7jbWXBFBtcBV4uPG0ks5toNGygaJpZM4TRxMF> .

[ghost]

double.Parse with NumberStyles.Number will parse out the numbers from string, if string has no alphabet. Use NumberStyles.Float to make it fail.

[DonaldRich]

Sorry, no. The only difference between NumberStyles.Number and NumberStyles.Float is that Number allows trailing sign and thousands while Float allows exponent. Number should not recognize "0,12" in a culture using commas as the thousands separator, but should recognize it in a culture using the comma as a decimal point. No matter what combination of NumberStyles are used "0,12" is not a valid number when using a culture which does not use the comma as a decimal point. If NumberStyles.Number is ignoring non-digit characters this is wrong since is is a composite format allowing leading signs, trailing signs, thousands separators and decimal points.

…

On Fri, Apr 13, 2018 at 9:34 PM, kasper3 ***@***.***> wrote: double.Parse with NumberStyles.Number will parse out the numbers from string, if string has no alphabet. Use NumberStyles.Float to make it fail. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <https://github.com/dotnet/corefx/issues/29059#issuecomment-381224324>, or mute the thread <https://github.com/notifications/unsubscribe-auth/ABuuDZuHIsz3OSWECfH3G3BdyNf7uNLQks5toO_SgaJpZM4TRxMF> .

[ghost]

Looking at the code, https://github.com/dotnet/corefx/blob/27149e4/src/Common/src/CoreLib/System/Number.Parsing.cs#L399, it seems like it doesn't account for position of thousand separator (except when , appears at position 0 it returns false), but only its presence. Even double.TryParse("333,333,22,22,1,1,1,1,,,,,,,", NumberStyles.Number, CultureInfo.GetCultureInfo("en-US"), out double number) is returning true.
@mazong1123, @stephentoub, the behavior is consistent with .NET Framework, but undesired. Can we make a breaking change in this area?

[mazong1123]

Sounds like a bug. @stephentoub @jkotas do we have any historical reason for missing this validation?

[ghost]

Tagging subscribers to this area: @tannergooding
Notify danmosemsft if you want to be subscribed.