2011-10-02

It's not about the money -- it's actually about currency

I hope whoever decided that "currency symbol" was a part of the locale (what normal folks call the "regional settings") is slightly regretting that decision right now.

The problem with this is that applications and documents are usually not tied to regions. If you use a dynamic "insert currency symbol here" in any data that is used in multiple regions, the results will be wrong. For example, Analysis Services allows you to associate format strings with cells. Picking "Currency" just communicates to client applications that it's about money somehow. They have little choice but to apply the default currency symbol. Analysis Services actually has proper support for multiple currencies, but of course using that properly is much harder than just slapping on a format string.

This is very much like the issue of storing time without a time zone. For time it's actually worse because it can lead to loss of information: local time containing no indication of DST is ambiguous, to the point where you can no longer tell what the proper UTC time was if the time falls within the hour for applying DST. For currency, it's almost always possible to determine what currency type was actually intended and add it after the fact. For both time and currency, adding support to your application to convert between different time zones/currency types can be a significant amount of work.

Think extra hard before you use "currency" without any indication of type. Any sort of business application that sees serious use will almost certainly require international support of some kind. The least you can do is make sure monetary amounts are not ambiguous, no matter where your application is running. If you are designing a database, consider storing the currency type with the currency. If you're writing an application, do not accept monetary input if it lacks a currency type and do not produce output without a currency type -- if you have to assume one, try to codify the assumption somewhere outside your application.

Note that Excel gets this right (at least Excel 2007), even though it's ignorant of currency types: if you format a value as currency, Excel takes the symbol from your regional settings, but it stores the format string with the cell. If users with different settings open a workbook, they will see your currency symbol, not theirs (however, if they reapply the "currency" format, the symbol is overwritten -- Excel stores values and formats, not currency types).

If you're a developer, you may wish to customize your currency symbol to "¤" (the currency sign). This way, you can instantly spot the places where applications are using the currency symbol from the regional settings where this might not be appropriate.

No comments: