by Michael S. Kaplan, published on 2010/08/30 07:01 -04:00, original URI: http://blogs.msdn.com/b/michkap/archive/2010/08/30/10055550.aspx
It was over five years ago that I pointed out that Number format and currency format are not always the same.
In that blog, I pointed out that one could not necessarily assume that GetNumberFormat and GetCurrencyFormat will return the same results, because the number format and the currency format were two different things.
And that is entirely true -- it is why there is both LOCALE_SDECIMAL and LOCALE_SMONDECIMALSEP, both LOCALE_STHOUSAND and LOCALE_SMONTHOUSANDSEP, both LOCALE_SGROUPING and LOCALE_SMONGROUPING.
But it represents a very idealized view of locale data and what is involved with it.
Perhaps I was just a wild idealist then and now I know better, but with half a decade to think about it, I've decided to rethink this one a little.
Because there are really only two times that any of these three pairs of constants will return different data for any locale passed to GetLocaleInfo:
Now the latter case is because it is the one time that LOCALE_SDECIMAL and LOCALE_SMONDECIMALSEP are different (it uses . aka U+002e aka FULL STOP for the former and / aka U+002f aka SOLIDUS for the latter).
But just about anyone you talk to from Iran, they know with an exchange rate of over 10,000 Rial to the dollar it has been a long time since anyone has ever talked about any fractional Rial value (Dinars or otherwise) except in a metaphorical diddly/squat sense. Of those I asked many were unfamiliar with any expected difference in the decimal separator for the two different cases whatsoever, and those who were familiar with it considered it ridiculous to support for any time in the last century or longer.
Ironically, I was (many years back) one of the advocates for the Bidi algorithm exception that put U+002f in the "ES" (European Number Separator) category for bidi_class. Largely to preserve this largely theoretical behavior. Though I was just one of the chorus on that one, I did not lead they choir. This change helps fractional Rial currency values in Farsi/Persian, an edge case extraordinaire!
I don't know the exact period in history that fractional Rials became so "theoretical" so I am going to rely on what others have told me for that point.
Either way, six different fields exist in every locale, even though it could have been three all these years.
You can contrast this with a similar though separate case -- the one of some of the percent locale fields I described in And you can't set all of the properties all of the time... -- a case where some properties are separate but the underlying data is not (since none of them were ever different in the locale data).
We could have just saved ourselves the extra complication and not separate things until the need was proven and the difference actually mattered.
If the same problem came up in the future, I would not advocate the split (in either the interface or the underlying data) until there was proof that the split would be sensible and expected in actual usage.
Because A DIFFERENCE THAT MAKES NO DIFFERENCE SHOULDN'T MAKE A DIFFERENCE.
John Cowan on 30 Aug 2010 7:51 AM:
And a beggar came forward and asked,
What is Wealth, Master?
The Master spoke:
Gold is not Wealth.
A wealthy man without honor is not a rich man.
A beggar like yourself can be wealthy compared to a rich man without honor.
After all, would you consider a man without honor wealthy, even if his Dinar laid end to end would reach from here to the Temple of Toplat?
No, I wouldn't, the beggar replied.
Why is that? the Master asked.
A Dinar doesn't go very far these days, Master.
Besides, the Temple of Toplat is across the street!
--Kehlog Albran, _The Profit_.
Jan Kučera on 30 Aug 2010 11:17 AM:
Actually, one of the first things I do on a clean installation is setting the number decimal separator to the dot, keeping the money decimal separator to be the comma (Czech locale) - and I'm really thankful for that possibility! Some things do not seem to be needed when you live at the right place...
Michael S. Kaplan on 30 Aug 2010 1:04 PM:
That's a little scary....Why?
Alex Cohn on 5 Sep 2010 9:14 AM:
I agree with Jan.
A Czech-speaking person who lives in US is used to 2,718 for <b>e</b>, but she will use $200.12 to balance her account.
And this again brings me to the date formats. One cannot choose the string set for Sun-Mon-Wed, etc. So this dictates the "locale". All other details - like currency symbol, separators and such - may have to be reconfigured to match the expectations of a hypotetic Russian-speaking Israeli.
Michael S. Kaplan on 5 Sep 2010 12:36 PM:
One could make a custom locale, and get all of that customized, including day names!
Jan Kučera on 14 Apr 2011 12:36 AM:
One of the reasons is that lots of things break when you keep comma as a decimal separator. Still, some fascinating software, like Office 2010, succesfully ignores the customization on the input side (entering numbers in a font size box on the numeric keypad uses comma even if it the number decimal separator is customized to the dot), just for the pleasure to tell you that the entered number is invalid! Not mentioning numerical data imports to Excel or Quattro or similar, especially with CSV.
And keeping the accounting format using the comma - well, if the application is aware of the accounting format it is very likely able to respect any of your culture settings. And, you see numbers all the day, coming from all over the world, but prices in a currency - not so much, you are just used for the formatting belonging to that currency.
So yeah, the main reason is that the life get much more easier. You do not get upset so often, and do not need to make useless complaints to the vendors. I was really hurt when the guy from FedEx told me that I have to enter dots in their software/web because "there are only two bloody countries in the world using comma as a decimal separator and so I have to agree naturally, that it is absolute nonsense to support that"...