ToString("n") returns different decimal places on net5.0 vs netcoreapp3.1

[schotime]

Below you will find a simple example that illustrates the issue.
The below code prints 21.000 in net5.0
If I replace the TargetFramework with netcoreapp3.1 it returns 21.00
I'm running 16.8 VS community.

<Project Sdk="Microsoft.NET.Sdk">

 <PropertyGroup>
 <OutputType>Exe</OutputType>
 <TargetFramework>net5.0</TargetFramework>
 <!--<TargetFramework>netcoreapp3.1</TargetFramework>-->
 </PropertyGroup>

</Project>

using System;
using System.Globalization;

namespace ConsoleApp12
{
 class Program
 {
 static void Main(string[] args)
 {
 CultureInfo.CurrentCulture = new CultureInfo("en-US");
 Console.WriteLine(21.ToString("n"));
 }
 }
}

Let me know if you need any more info or I'm doing something wrong.

Tagging subscribers to this area: @tannergooding, @pgovind, @jeffhandley
See info in area-owners.md if you want to be subscribed.

Details

---

Issue meta data

Issue content:
	Below you will find a simple example that illustrates the issue. The below code prints 21.000 in net5.0 If I replace the TargetFramework with netcoreapp3.1 it returns 21.00 I'm running 16.8 VS community. <Project Sdk="Microsoft.NET.Sdk"> <PropertyGroup> <OutputType>Exe</OutputType> <TargetFramework>net5.0</TargetFramework> <!--<TargetFramework>netcoreapp3.1</TargetFramework>--> </PropertyGroup> </Project> using System; using System.Globalization; namespace ConsoleApp12 { class Program { static void Main(string[] args) { CultureInfo.CurrentCulture = new CultureInfo("en-US"); Console.WriteLine(21.ToString("n")); } } } Let me know if you need any more info or I'm doing something wrong. </td>
Issue author:		schotime
Assignees:	-
Labels:	`area-System.Numerics`, `untriaged` </td>
Milestone:	-

[tannergooding]

I am not currently able to repro:

In the screenshot above, I also printed the framework version as part of the first line, but I also tested without that addition.

The actual logic gets the number of decimal digits from NumberFormatInfo.GetInstance(null).NumberDecimalDigits (or passing in the user given provider in place of null), so I would expect that printing that returns 2 vs 3 on your box while it returns 2 both times for me.

@GrabYourPitchforks or @tarekgh, could this be an NLS related change?

[KalleOlaviNiemitalo]

@tannergooding, if I replace new CultureInfo("en-US") with new CultureInfo("en-US", useUserOverride: false), then the program outputs 21.000 with .NET 5.0 on Windows 10 20H2; but if I also define DOTNET_SYSTEM_GLOBALIZATION_USENLS=1, then it outputs 21.00. This seems a difference between Windows NLS data and CLDR.

[danmoseley]

Marking regression as it's an unexpected behavior change, if we believe it's correct we can remove the label (but it could possibly use a note in the ICU doc)

[tarekgh]

This is how the Unicode standard CLDR data define it. So this is expected change. Windows is converging to CLDR as indicated in this blog too. The benefit here is now we are conforming with Unicode standard and will have consistent behavior across platforms and OS's.

@schotime could you please elaborate what issue you are running into because of that?

[schotime]

@tarekgh It was only used in a test here https://github.com/schotime/NPoco/blob/v5/test/NPoco.Tests/FluentTests/QueryTests/QueryProviderTests.cs#L349 to test out the query provider handling it, so it's not that big of a deal, as long as the currency one hasn't changed.

But nonetheless it broke the build right before I was about to release, so thought I'd mention it here. Especially when the doco says its 2 decimal places in its example.

[tarekgh]

@schotime Thanks for the info.

In general it is not right to assume such formatting will not change. This is happen most of the time with many cultures and would be good to not take any dependency on that. Usually we recommend users to immune themselves from such breaks either by using like Invariant culture which we keep it not changing. Or to use specific format when formatting. In your case example, using "N2" would be more reliable to do. I hope you can do the same with the currency format too.

The doc examples are just examples showing different format and not intended to say this never change. We try to fix our docs in such old existed examples. but thanks for pointing to that.

Do you have any more questions or is it ok to close this issue?