CurrentRegion is not based on the GEOID

by Michael S. Kaplan, published on 2005/12/10 15:31 -05:00, original URI: http://blogs.msdn.com/b/michkap/archive/2005/12/10/502415.aspx

From the mostly excellent movie Notting Hill:

Hugh Grant: Do you say 'No' to everything?

Julia Roberts: {thinks for a moment} No.

Kind of fun when you argue against a point by playing into it, huh? :-)

I was reminded of this the other day.

You see, some people think I am under the delusion that I am always right. Interestingly, those people are incorrect....

There was an old newsgroup post I did back in February of 2005, where (when talking about the Win32 settings that inspired the managed settings) I said:

I agree with you on the confusion. I think the logic was that there were enough subtle differences between the .NET framework analogue to the Win32 locale that a new name seemed like the easiest way to capture the fact that they are indeed two different (if analogous) beasts....

So, it is like this:

default user locale (standards and formats)
becomes
CurrentCulture

default user UI language
becomes
CurrentUICulture

User GEOID (location)
becomes
CurrentRegion

Now that third point there is definitely 100% wrong. The CurrentRegion is also based on the default user locale.

This would be yet another example of the problem I pointed out in GEOID -- The LCIDs maligned little brother....

We honestly ought to be basing something called RegionInfo.CurrentRegion on the actual setting in Regional and Language Options that is based on region, rather than the one based on 'standards and formats.' Though there are several reasons why this would not work very well:

• The list of regions of the data supporting RegionInfo is the same as the list of locales/cultures (since the original architecture of RegionIno was based on an attempt to split the region-specific pieces of locales)
• The list of regions underlying the GEOID is larger and thus you can have settings in Windows that would not be available in the .NET Framework
• One of the original constructors for RegionInfo takes an LCID, not a GEOID
• The CurrentRegion property is documented as getting "...the RegionInfo that represents the country/region used by the current thread." while the actual GEOID setting is not really thread based (there is some basis for the behavior of culture settings having a thread basis, even though I think the thread locale really sucks
• People just plain aren't using GEOIDs where they probably ought to be, and our team is not an exception to this!

Anyway, sorry that I was incorrect in that newsgroup posting. It would be easy to chicken out and claim that the reason I was wrong is that the current behavior is wrong, but given the points above it is clearly part of the design. So I will just take my lumps and try to keep doing better....

This post brought to you by "«" (U+00ab, LEFT-POINTING DOUBLE ANGLE QUOTATION MARK)

referenced by

go to newer or older post, or back to index or month or day