Sometimes the things that used to be different aren't anymore

by Michael S. Kaplan, published on 2011/04/29 16:02 +02:00, original URI: http://blogs.msdn.com/b/michkap/archive/2011/04/29/10159418.aspx

The other day, colleague Tom asked me:

Why would LOCALE_IINTLCURRDIGITS ever be different from LOCALE_ICURRDIGITS ?

This question is a lot more complicated than one might first imagine.

We'll start with the definitions:

• LOCALE_ICURRDIGITS - Number of fractional digits for the local monetary format. The maximum number of characters allowed for this string is two, including the values 0-9 and a terminating null character. For example, 200.00 has a value of 2 because there are two fractional digits, while 200 has a value of 0 because there are no fractional digits displayed.
• LOCALE_IINTLCURRDIGITS - Number of fractional digits for the international monetary format. The maximum number of characters allowed for this string is three, including a terminating null character. For example, the number of fractional digits for the international monetary format of US Dollars is 2, as in $345.25.

You may want to read these definitions a few different times each, so you can try to understand the difference.

Did it work? Do you understand the difference?

Me neither.

Without explaining the difference between "local" and "international" in this context, it is not clear that they are any different -- or if so, how they are different.

Let's look for other clues.

If you look at the big list of Locale Information Constants, LOCALE_IINTLCURRDIGITS claims to be a part of Constants Used by GetLocaleInfo and GetLocaleInfoEx Only, while LOCALE_ICURRDIGITS claims to be a part of Constants Used by Both SetLocaleInfo and GetLocaleInfo/GetLocaleInfoEx. That's a genuine difference.

The CURRENCYFMT Structure, the NumberFormatInfo class, and the Microsoft Locale Builder

all have one thing in common: just one setting.

The underlying data store in locale.nls also has only one item in it, though the original source files still have two items. One just gets ignored when the file is being built.

At runtime, the only difference is that one only works for setting while the other works for getting and setting. They are both using the same value (if you set LOCALE_ICURRDIGITS then LOCALE_IINTLCURRDIGITS is also changed).

So the difference is that there is no actual difference!

This was not always the case though, mind you.

If you go back to Windows XP and Server 2003, they were two separate items that could be different, and there were two theoretical purposes:

• When using a locale with decimal formatting info very different from the values of other locales (e.g. Japanese or Persian, where talk of fractional values is very uncommon), this would make formatting other currency values easier (i.e.g you know how many decimal places to use when you need fractional values even if you usually wouldn't ever need to know);
• When dealng with locales transitioning to the Euro, LOCALE_ICURRDIGITS could be used for the locale's currency symbol and LOCALE_IINTLCURRDIGITS could be used for the other currency.

In practice, purposes such of these were represented in the data for some locales in Server 2003 and earlier -- Japan, for example did indeed have a LOCALE_ICURRDIGITS of 0 and a LOCALE_IINTLCURRDIGITS of 2. But this kind of difference vanished by the time Vista's locale data shipped. Note that formatting never used it, the documentation was never clear, and despite disappearing from everywhere as a distinct item there is a real lack of complaining about it.

Think of LOCALE_IINTLCURRDIGITS as an evolutionary blind alley in the development of Windows locale data.

And the documentation simply hasn't caught up to describng this vestigial tail (that catchup is slightlf perilous for as long as it reasonable to use the docs for Windows XP/Server 2003 and earlier, unless the full scope of the setting is also documented).

Perhaps it just need a kickass KB article.

Or a kickass blog. :-)

referenced by

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