Given the following two cultures:
CultureInfo c1 = InvariantCulture;
CultureInfo c2 = new CultureInfo(\"en-US\");
and i were to examine eve
There are some actual differences (check both values in a Watch window), but the most relevant difference is the intent. InvariantCulture shows your intent of parsing some data in a culture independent, if english related, manner, whereas en-US declares your actual intent to parse data in a US specific manner.
It is very important to consider the intent of the data. If you are serializing make sure to use InvariantCulture.
See: http://msdn.microsoft.com/en-us/library/system.globalization.cultureinfo.aspx
From the microsoft documentation:
Dynamic Culture Data
Except for the invariant culture, culture data is dynamic. This is true even for the predefined cultures. ...
Caution
When saving data, your application should use the invariant culture, use a binary format, or use a specific culture-independent format. Data saved according to the current values associated with a particular culture, other than the invariant culture, might become unreadable or might change in meaning if that culture changes.
I just encountered this recently where the user had his Region and Language settings set to English (United States), but had chosen his personal date format to dd-MMM-yy. He received a project from a client with a date in the default en-US format "4/29/2010 1:45:30 PM" and the code:
customValue = DateTime.Parse(customValue.ToString(), CultureInfo.CreateSpecificCulture("en-US"));
threw an exception because his local preferences override what the typical en-US format.
I know they have a different CultureName
and LCID
(see this list).
Additionally, the currency symbols are different - ¤ for InvariantCulture and $ for en-US.
From InvariantCulture:
It is used in almost any method in the Globalization namespace that requires a culture.
Suggesting that for the most part, they are interchangeable. However, the names do state intent, so you should think about that when using CultureInfo
.
Well, if you look at what your snippet of code might produce:
CultureInfo c1 = CultureInfo.InvariantCulture;
CultureInfo c2 = new CultureInfo("en-US");
Console.WriteLine( c1.DateTimeFormat.ShortDatePattern.ToString());
Console.WriteLine( c2.DateTimeFormat.ShortDatePattern.ToString());
Console.WriteLine( c1.DateTimeFormat.LongDatePattern.ToString());
Console.WriteLine( c2.DateTimeFormat.LongDatePattern.ToString());
Console.WriteLine( c1.NumberFormat.CurrencyDecimalDigits.ToString());
Console.WriteLine( c2.NumberFormat.CurrencyDecimalDigits.ToString());
Console.WriteLine( c1.TextInfo.IsRightToLeft.ToString());
Console.WriteLine( c2.TextInfo.IsRightToLeft.ToString());
You'll see some differences:
MM/dd/yyyy
M/d/yyyy
ffffdd, dd MMMM yyyy
ffffdd, MMMM dd, yyyy
2
2
False
False
And just think, when the US loses it's backbone and decides to start using European style dates or moves to the metric system (the metric system is the tool of the devil! My car gets forty rods to the hogshead and that's the way I likes it!), the InvariantCulture can just coolly and smoothly stay the way it is. So all those dates you've stashed away in a database in text form using the InvariantCulture will continue to just work...
Short answer yes. InvariantCulture is what it says, not a specific culture. It is english, but not a specific region
you can read more about it here : MSDN
Yes.
For example: InvariantCulture uses the international symbol for currency: "¤" versus the dollar sign: "$" when formatting currency.
For the most part, however, they're very similar.
Edit: List of differences between en-US
and Invariant
:
en-US Invariant
===================== ================== ==================
Number 123456.78 +123456.78
Currency Symbol $ ¤
Currency $123456.78 ¤123456.78
Short Date 1/11/2012 01/11/2012
Time 10:36:52 PM 22:36:52
Metric No Yes
Long Date Wednesday, January 11, 2012 Wednesday, 11 January, 2012
Year Month January, 2012 2012 January