Many of you have observed that some things don't work with neutral cultures.  Some fields require culture specific data to behave correctly. 

For example, in en-US, you might expect M/d/yyyy for a date pattern, however en-GB has dd/MM/yyyy and en-ZA has yyyy/MM/dd for their short date pattern.  So if all you have is an http-request for "en", you don't have enough information to format a date.

For that reason many of the CultureInfo properties will fail for neutral cultures.  CultureInfo.DateTimeFormat is one of those as demostrated by the previous example.

So what do you do if you really need to format a date, and all they gave you was a neutral culture, like en?  For that we have CreateSpecificCulture, so instead of calling CultureInfo.GetCultureInfo("en"), you'd call CultureInfo.CreateSpecificCulture("en").  For "en" this will return an "en-US" CultureInfo.  Note that CultureInfo.CreateSpecificCulture("en-US") also works, so if you are uncertain whether an input is neutral or not you can just use CreateSpecificCulture and avoid the extra tests.  This could be a problem if your client is en-GB or en-CA or en-AU.

CreateSpecificCulture does have a few caveats.

The first is that it will return an ARBITRARY culture that has the requested language.  For en it will return en-US even if your user's in Australia or the Canada.  For fr it will return fr-FR even if you're user's in Canada.  That's great if your "en" http request is coming from the US, not so great if its coming from somewhere else.

Since "en" by itself doesn't provide enough information (like a country), there's not much we can do to avoid that problem, so apps need to be aware of that problem.  You might choose to display long dates instead of short dates do avoid confusion between MM/dd or dd/MM for example.

In some cases the specific culture may seem offensive to users or be geopolitically incorrect, so use them with care.  For example, some users might feel offended if the MM and dd are "backwards" to their expectation. 

The second issue is that Chinese (zh) will throw an exception instead of returning a specific culture because its not possible to pick a geopolitically correct culture for Chinese.  You may want to test for this case explicitly.

Lastly, as with other culture properties, different machines could have different custom cultures installed, which could have different values for the specific culture, so it'd be best if applications didn't rely on a particular specific culture relationship, particularly when custom cultures could be installed on the machine.

So that's CreateSpecificCulture().  Use it when you need to, but try to use it sparingly and carefully so that your users don't get confused about date formats or some such.