3

We have code in our system to format numbers and currency according to the regional settings selected by the user. One of our users has selected en-ZA and noticed that the digit grouping and decimal separators have changed with our migration to .NET 4.0.

I wrote a snippet of code to illustrate this change:

using System;
namespace regional
{
    class Program
    {
        static void Main(string[] args)
        {
            var ci = new System.Globalization.CultureInfo("en-ZA");
            var output = 1234567.00m.ToString("c", ci);
            Console.WriteLine(output);            
        }
    }
}

Under .NET 3.5, we get output that looks like this:

R 1,234,567.00

Under .NET 4.0, we get output that looks like this:

R 1 234 567,00

What accounts for the change in decimal separator and digit grouping between .NET 3.5 and .NET 4.0?

According to Wikipedia, "When South Africa adopted the metric system, it adopted the comma as its decimal separator." This implies that this setting changed at some point, but I still don't have insight as to why the behavior is different between the different framework versions.

Bernard Chen
  • 6,437
  • 5
  • 23
  • 27
  • 1
    In addition to what Tom said in his answer: If you have problems with code that breaks because of this, you're doing something wrong in the first place. Passing values around should always be done with a correct datatype, and parsing user inputted strings should always be done with the current thread culture in mind - if you do it that way, a change in the localization will only be seen at the user end, nowhere else. – Tomas Aschan Jul 24 '10 at 10:19
  • 1
    The change in localization only being seen at the user end. In this case, the user thinks that the change is incorrect. Was there something in my question that made it seem like it was being seen somewhere other than at the user end? – Bernard Chen Jul 25 '10 at 03:50
  • 2
    Short answer is that the .NET 3.5 version was wrong. The prescribed format is space for grouping and comma for decimal symbol. Most people do not use the prescribed format (e.g. in Excel), relying periods for decimal symbols, but that is irrelevant. The .NET 4.0 version reflects the official prescribed format. – Francois Botha Aug 08 '19 at 13:29

1 Answers1

2

The .net team review stuff like this based on consumer feedback - presumably enough people petitioned them to say the existing settings were incorrect so they changed them.

http://msdn.microsoft.com/en-us/library/dd997383.aspx#updated_globalization_property_values

basically says "we update globalization settings between versions", and

http://msdn.microsoft.com/en-us/library/dd997383.aspx#getting_current_globalization_information

says that from Windows 7 onwards they in fact load globalization data from the OS (so potentially en-za will appear differently under different operating systems, at different points in time). Also

Because of the ever-changing world, globalization information is subject to change at any time; developers should not expect the values of globalization properties to persist between releases, or even for the same release of the .NET Framework

Tom Carver
  • 962
  • 7
  • 17
  • Thanks for the answer. My guess is that if a particular customer wants a different set of formatting rules that are no longer available for en-ZA, I'm going to have to figure out how to support a custom CultureInfo. – Bernard Chen Jul 25 '10 at 03:55
  • It looks that way, and possibly that you'll have to do that even if they just want a *consistent* set of formatting rules - we're all potentially one windows update away from a change in these settings (from Win 7 onwards)! – Tom Carver Jul 25 '10 at 08:41
  • South Africa is predominantly a period-based culture, so unfortunately the process must have "hiccuped" somewhere – Savage Jul 30 '18 at 10:40