Why is .NET "de-CH" culture number group separator different locally and on Azure?

Question

I am seeing a different Unicode character as the number group separator for the "de-CH" culture when running on a local desktop and in Azure.

When the following code is run on my desktop in .NET Core 3.1 or .NET Framework 4.7.2 it outputs 2019 which looks like an apostrophe but is not the same.

When run in Azure, for instance in https://try.dot.net or (slightly modified) in an Azure function running on .NET Core 3.1 (on a Windows based App Service) it results in 0027, a standard ASCII apostrophe.

using System;
using System.Linq;
using System.Globalization;

Console.WriteLine(((int)(CultureInfo
    .GetCultureInfo("de-CH")
    .NumberFormat
    .NumberGroupSeparator
    .Single())) // Just getting the single character as an int
    .ToString("X4") // unicode value of that character
    );

The result of this is that trying to parse the string 4'200.000 (where the apostrophe there is Unicode 0027) on local desktop using "de-CH" culture fails, but it works in Azure.

Why the difference?

Answer 1

This Microsoft blog by Shawn Steele explains why you shouldn't rely on a specific culture setting being stable (Fully quoted because it is no longer online at MSDN):

https://web.archive.org/web/20190110065542/https://blogs.msdn.microsoft.com/shawnste/2005/04/05/culture-data-shouldnt-be-considered-stable-except-for-invariant/

CultureInfo and RegionInfo data represents a cultural, regional, admin or user preference for cultural settings. Applications should NOT make any assumptions that rely on this data being stable. The only exception (this is a rule, so of course there's an exception) is for CultureInfo.InvariantCulture. CultureInfo.InvariantCulture is supposed to remain stable, even between versions.

There are many reasons that cultural data can change. With Whidbey and Custom Cultures the list gets a little longer.

• The most obvious reason is that there is a bug in the data and we had to make a change. (Believe it or not we make mistakes ;-)) In this case our users (and yours too) want culturally correct data, so we have to fix the bug even if it breaks existing applications.
• Another reason is that cultural preferences can change. There're lots of ways this can happen, but it does happen:
  • Global awareness, cross cultural exchange, the changing role of computers and so forth can all effect a cultural preference.
  • International treaties, trade, etc. can change values. The adoption of the Euro changed many countries currency symbol to €.
  • National or regional regulations can impact these values too.
  • Preferred spelling of words can change over time.
  • Preferred date formats, etc can change.
• Multiple preferences could exist for a culture. The preferred best choice can then change over time.
• Users could have overridden some values, like date or time formats. These can be requested without user override, however we recommend that applications consider using user overrides.
• Users or administrators could have created a replacement culture, replacing common default values for a culture with company specific, regional specific, or other variations of the standard data.
  • Some cultures may have preferences that vary depending on the setting. A business might have a more formal form than an Internet Café.
  • An enterprise may require a specific date format or time format for the entire organization.
• Differing versions of the same custom culture, or one that's custom on one machine and a windows only culture on another machine.

So if you format a string with a particular date/time format, and then try to Parse it later, parse might fail if the version changed, if the machine changed, if the framework version changed (newer data), or if a custom culture was changed. If you need to persist data in a reliable format, choose a binary method, provide your own format or use the InvariantCulture.

Even without changing data, remembering to use Invariant is still a good idea. If you have different . and , syntax for something like 1,000.29, then Parsing can get confused if a client was expecting 1.000,29. I've seen this problem with applications that didn't realize that a user's culture would be different than the developer's culture. Using Invariant or another technique solves this kind of problem.

Of course you can't have both "correct" display for the current user and perfect round tripping if the culture data changes. So generally I'd recommend persisting data using InvariantCulture or another immutable format, and always using the appropriate formatting APIs for display. Your application will have its own requirements, so consider them carefully.

Note that for collation (sort order/comparisons), even Invariant behavior can change. You'll need to use the Sort Versioning to get around that if you require consistently stable sort orders.

If you need to parse data automatically that is formatted to be user-friendly, there are two approaches:

• Allow the user to explicitly specify the used format.
• First remove every character except digits, minus sign and the decimal separator from the string before trying to parse this. Note that you need to know the correct decimal separator first. There is no way to guess this correctly and guessing wrong could result in major problems.

Wherever possible try to avoid parsing numbers that are formatted to be user-friendly. Instead whenever possible try to request numbers in a strictly defined (invariant) format.