CultureInvariatorCulture in Plain English
I know the culture rule for dates / numbers is enough for a whole book, I think I have a simple question though ..
Does using InvariantCulture basically mean you are explicitly defining which culture the value will be injected / displayed in (date / number / all)? And does it override any other culture settings (such as the user agent setting)?
If the app is built for one and only one culture audience, does it make sense to use InvariantCulture and define how you want to enter / display values each time?
source to share
Does using InvariantCulture basically mean you are explicitly defining which culture the value will be injected / displayed in (date / number / all)?
Not. It's just a culture that looks a bit like American English, except for a few things like the currency sign. It is commonly used for formatting / consuming text that needs to be understood or produced by another computer and not a human.
If the app is built for one and only one culture audience, does it make sense to use InvariantCulture and define how you want to enter / display values each time?
No, you would use the appropriate one CultureInfo
for this culture. You can also explicitly define the format of dates, etc., but this is an orthogonal problem. It may be best to use one of the standard standard formats for this culture, but if none of them suit your needs, you can always be explicit.
source to share
InvariantCulture
Independent of any culture or any factor. For example, if you use the new CultureInfo ("en-US"), it will get you the English US culture (which may not be relevant US English Culture
because the OS gives you the ability to change these parameters in the control panel), it will return the modified version of the culture "en- US "if any custom formatting has been applied to it.
In other words, it InvariantCulture
always gives you a Culture that can never be changed in systems.
Suppose you want to serialize some value (say double) and go to another application or some other thread that works in different cultures leads to serious problems.
Consider the following code
Thread.CurrentThread.CurrentCulture = new CultureInfo("fr");
double source = 455.62d;
string serialized = source.ToString();//455,62 since `, is the decimal seperator` in "fr"
Thread t = new Thread((x) =>
{
double deserialized = double.Parse(((string)x));
Console.WriteLine(string.Format("Deserialized value is {0}", deserialized));//outputs 45562
});
t.CurrentCulture = new CultureInfo("en-US");
t.Start(serialized);
Do the numbers have a more correct meaning? consider this line AccountBalance
:?
Hope it helps
source to share
With that in mind, the DateTime
best advice I can give is to use CultureInfo.InvariantCulture
for ParseExact
and ToString
if you have the exact format. (You can also use it with Parse
if you know your input format follows the invariant culture formats, but I usually avoid that.)
Don't use invariant culture when interacting with the user.
Keep in mind that culture contains several elements, including ordering of day / month / year parts, date / time separator characters, character encodings and language names for days of the week, months of the year, and abbreviations including am / pm.
Some examples of when you should use invariant culture:
- Files on disk, especially text files of a predefined format
- External APIs, especially JSON or XML
- Unit tests, unless you specifically test for culture issues.
Some examples of using a specific culture, for example en-US
:
- User interface
- Reports
source to share