77

Many high-level programming languages have built-in features to format a number with a system-dependent currency symbol:

-- Outputs $100.00 (en-US) or € 100,00 (de-AT)

Console.WriteLine(100.ToString("C"));  // C#
? FormatCurrency(100)                  ' VBA
...

I've been developing business software for more than 20 years, and I've not yet found a single use case for this feature.

The thing is: $ 100 is a completely different amount of money than € 100. If I store 100 in a database field and just "format the value as currency", the user will get a different amount of money depending on their system setting.

Even if I always override the locale, that does not necessarily mean that the currency symbol will stay constant: de-AT (together with a lot of other locales) switched from ATS to € about 20 years ago. In that case, the amount of money displayed would not only vary by locale but also by operating system patch level.

What am I missing? For which use case is this feature actually useful?

Heinzi
  • 9,646
  • 3
  • 46
  • 59
  • Seems to be a rollback default value like optional param: just to make sure at least something will be there. More than that, I would prefer an exception there rather than unpredictable default with even more unpredictable consequences in a real world. – Zazaeil Sep 01 '20 at 13:09
  • 4
    Not to mention the fact that many countries' currency symbol is $. Mexican pesos, colombian pesos, trinidanian dollars, etc. share the same symbol $ with the US dollar. – Tulains Córdova Sep 01 '20 at 14:43
  • 20 years ago, even if you had a multi-currency system in place, at some time you had to switch to the euro, convert amounts and priced and adopt strict rounding rules. Changing local currency of a productive system is never easy regardless of how you’re doing. I remember I had a lot of projects of this kind at that time ;-) – Christophe Sep 01 '20 at 15:39
  • 2
    Note that "$100" for USD only correct for locales that put currency code in front of the value. Indeed 100 USD must be printed as "100 $" for Russia or Canada (French only text so)... But indeed you know that and just oversimplify your sample :) – Alexei Levenkov Sep 02 '20 at 05:02
  • I can mention when it's not useful: writing server code, where the server is hosted with on an OS with a different locale than the client. Also applies to time (and timezones). – Matthieu M. Sep 02 '20 at 08:45
  • 2
    I'd like to point out that, at least for .NET, ToString and other formatting methods will fall-back to the System locale, but can be overridden an application and thread level or specified as a parameter. – Simon Sep 02 '20 at 10:04
  • Do you know how many BAs have no idea that formats for dates/time/money/postcodes etc etc etc are different from their own country's, but expect developers to write code that handles every one? At least with date/time/money the OS (or more likely, the framework) handles the formatting differences for us. – Neil Sep 02 '20 at 14:06
  • I think this was one of those features that was designed back in the 80s, by programmers who didn't fully think through the complexity of the problem, and put in a "solution" that was too simple to actually solve it, and instead creates a trap for the unwary. – Glenn Willen Sep 02 '20 at 18:13
  • 5
    `print(f'${100:f}') ` does not do any currency formatting. It simply prints the integer `100` as a fixed point number with the default number of 6 decimals and adds the string prefix `"$"` in front. – ruohola Sep 02 '20 at 21:36
  • 2
    @ruohola: Now this is embarrassing... you are completely right, of course. Looks like Python "did it right". I have removed that example. – Heinzi Sep 03 '20 at 08:19

7 Answers7

35

Is there a use-case for build-in currency formatting?

Basically, with currencies you have two ways of working:

  • in a currency-aware environment, where people register amount sometimes in local and sometimes in foreign currency: you will never use the default built-in feature. Instead you’ll store a currency amount and a currency code.
  • in a currency-neutral environment. Believe it or not, most private people and most small businesses around the world work only with one local currency, which happens to be the currency configured in their OS settings and never changes. Using the build-in formatting then takes advantage of this fact, and use OS configuration instead of forcing you to add your own configuration step in your software for this. By the way, this formatting has generally also the advantage of using the right decimal and thousand separators.

So yes, there is a use-case for this feature.

But with limitations

This being said, I’m not sure that this standard feature works well and out of the box and in a portable way with:

  • currencies that are expected to be displayed with a different number of decimals than the usual two (such as JPY which are usually shown with no decimals at all, or KWD which take 3 decimals) (if you know, please comment)
  • local financial usages of showing negative amounts either with a minus, or as a positive number between brackets
  • other practical usages, such as showing the currency symbol to the left (US, UK) or to the right (FR, DE) of the amount.

Although OSes may handle these rather well (e.g.: Windows, macOS), the OS independent programming language implementations are sometimes full of surprises and missing flexibility, which could limit the use-case of this feature, but for other reasons.

Glorfindel
  • 3,137
  • 6
  • 25
  • 33
Christophe
  • 74,672
  • 10
  • 115
  • 187
  • 8
    *"most private people and most small businesses around the world work only with one local currency"* - the adoption of the Euro blew that assumption out of the water. That exact event is now receding into the past, but the possibility that a single locale will at some point change its working currency (whether through a currency union, or through revaluation) is a very real possibility to be accomodated in the design of any modern financial system. – Steve Sep 01 '20 at 14:21
  • 19
    @Steve 40 years ago, when I was a teen, I lived on French German border. I had two boxes for my pocket money, one in FRF and one in DEM. But even in those times, most of the software dealt only with one (local) currency, and multi-currency was a rare optional feature that only SMB’s in border regions really asked for. So, believe it or not, this reality of the local currency was already there long before the euro. It has nothing to do with currency, but economic reality of most brick&mortar SMBs, which is not the reality of international finance. – Christophe Sep 01 '20 at 14:41
  • 9
    +1 for using currency ISO codes (USD, EUR, COP, BTC, etc.) instead of symbols. Many countries' currency symbol is $. Mexican pesos, colombian pesos, trinidanian dollars, etc. share the same symbol $ with the US dollar. – Tulains Córdova Sep 01 '20 at 14:45
  • 11
    @Steve Now don’t misunderstand me: personally I work in an international financial environment and I always preferred multi-currency (already as teen, as explained above). But personally I also prefer to use an open source software developed in the US that will display currency-less amounts with a euro symbol because it uses os formatting, rather than hard-coded dollars symbol which would make it instantly useless here, if would have to print anything. And that is the use-case I was advocating: small software designed for very basic but universal needs. – Christophe Sep 01 '20 at 14:48
  • @TulainsCórdova Thank you! Interesting to know that $ is not always USD. Indeed,I find the ISO codes less ambiguous. I was exploring some Windows settings and was surprised that it allows only one single symbol for the currency. On the other side, on tiny phone or watch displays,it can sometimes help to spare some “screen-estate”. My whole point here is not to defend the OS use at all cost, but on contrary, to explain that despite the many arguments (and my personal preference) for multicurrency with ISO codes, there are objectively cases where standard formatting could make sense. – Christophe Sep 01 '20 at 15:03
  • 15
    @Christophe: I think you've misinterpreted Steve's comment. He's saying that the adoption of the Euro *broke* the only-ever-one-currency assumption for many users. (If you had a ledger entry representing DM 300, you wouldn't want it to suddenly claim "€ 300" the next time you updated your OS.) – ruakh Sep 01 '20 at 21:37
  • 2
    @Steve That assumption is still valid to the vast majority of people in the world hence the qualifier "most" in the statement – slebetman Sep 02 '20 at 00:13
  • 2
    @ruakh It broke it over the transition period, but a few years later most of the cases were "fixed" again. People can live with "records that I have no reason to look at" now showing the wrong symbol – Caleth Sep 02 '20 at 09:10
  • @Caleth, it depends on exactly how the system works. Custom software, and analysis of historical data, is vastly more common today than 20 years ago, and the risk in future is that many operationally important systems simply wouldn't work across a currency transition (not unlike the risk that was perceived for the Y2K problem), unless the amounts recorded in the historical data were retrospectively revalued (in bulk and on the eve of the transition) into the new currency. – Steve Sep 02 '20 at 13:38
  • 1
    The transition to € is not necessarily a thing of the past. There is still plenty of countries in Europe that are not in the euro zone at the moment. Nobody can forsee whether that will still be the case in 10 or 15 years. And in the other direction as well. Nobody knows if all the countries will stick with the euro. Anybody remembers the word Grexit? And I reject the idea that multi-currency is an issue for international finance. In any touristy region in Switzerland you will be able to pay your cup of coffee in € instead of CHF if you want – Manziel Sep 02 '20 at 14:09
  • 1
    Even if a single currency was completely reliable norm for a country, you can't guarantee a user won't have their OS settings in English or their native tongue. Thus leaving those to wonder what they're actually paying. I feel the only use case for this is school math problems, where you simply need to indicate "money". – csiz Sep 02 '20 at 19:21
  • 1
    @csiz yes, that’s a risk. It can also be an inconsistent setting between between server and one of the client. It’s far from being perfect. But this is a drawback a lot of people have lived with (and still live with when using monetary format in Excel, so a limitation that didn’t prevent the success if the oroduct). – Christophe Sep 02 '20 at 19:32
  • @Manziel Plenty of other currencies have been changed throughout history and even more will change in the future. This does not change that to most people the records that matter are all recent enough that any transition from one currency to another is so far in the past that it's simply not relevant. 28 year old records are simply not relevant to the vast majority of people. Historians can deal with any conversion when they think it's required. For the rest of us, three year old records are usually more than enough. The usecase is single computer software, so no servers, no mobile devices. – Clearer Sep 03 '20 at 22:47
  • You have multiple fallacies. First, you assume that your users are only interested in present data with the definition of present being the day your system software was programmed. Second you assume that anyone who needs more than this "present" can easily write their conversion. Third, just because people have been living with locale dependent brittle software for decades and learned to work around it, this does not mean that this is a good thing or even acceptable when writing new software. – Manziel Sep 04 '20 at 07:08
  • 1
    @Manziel Any complexity has to be justified, otherwise it is simply extra time sink and a source of bugs. A LOT of cases are solved just fine by "this costs X money". Eg software for a restaurant. Even during currency transition - you are going to change prices anyway to avoid weird prices like 12.34 eur for a meal. So just change numbers a bit more and you are all set. – Zizy Archer Sep 04 '20 at 09:59
  • This is plain wrong. Specifying explicitly what currency to use does not add any complexity. In the development phase both are of equal cost. It creates only obvious and always reproducible wrong behavior (a product always costs 1DM). Using a system dependent currency symbol does the opposite. It creates a non-obvious wrong behavior (sometimes it costs 1 DM, 1€, 1$), it is only reproducible if you have the user's locale set and 99% of users are not even aware of such things as locales. It will not appear in bug reports. This is adding complexity and wasting to the maintenance phase – Manziel Sep 04 '20 at 11:21
  • @Manziel it does add complexity, since the user manually has to provide the currency to use. So there has to be some configuration dialog, persistence of this configuration and think about what happens if the user changes the configuration - this is added complexity and creates expectations, when for most people saving money as a simple untyped number and displaying with standard formatting just works. – Falco Sep 04 '20 at 11:42
  • This is a classic YAGNI example. So many people here argue that currencies rarely change and that is the point. If you intend only use in one region, do not ask the user for it but simply fix the currency. If the currency changes, changing the symbol is the easiest part as you will need to decide how you handle historic data in your application. If you don't bother, users still know what they are dealing with. If you develop something like excel that can handle arbitrary data...well you are of course you are making the currency configurable and have a local dependent default – Manziel Sep 04 '20 at 12:35
  • @Manziel You are right: currencies change in fact all the time. In the 9 last years, 8 currencies were replaced, and 3 former currencies were definitively withdrawn. But so far, it never prevented users to cope with such changes, even with simpler software that was not designed for multi-currency. I think we should be modest enough to acknowledge that different needs require different solutions; That’s the aim of my answer: Ultimately, every product owner shall decide on whether a special app configuration is needed or if the locale configuration appears sufficient, based on pros & cons. – Christophe Sep 04 '20 at 13:01
  • "to the right (FR, DE)" FR and DE have been paying with Euros for a while now, placed to the left like the pound, so this no longer holds. – Mast Sep 04 '20 at 13:50
  • @Mast Is it possible that you confuse in the locale: the currency settings (symbol, name, number of digits) and the country or language specific settings (position, formatting)? I can confirm that the EUR is placed on the left in English, Irish and Maltese language only and on the right for all the other EU languages (see [official source](https://publications.europa.eu/code/en/en-370303.htm)). I even heard that in Switzerland, the decimal separator for currency amount is a dot whereas for all the other numbers it’s a comma (I could not find an official source). – Christophe Sep 04 '20 at 18:33
13

You are absolutely right, formatting using a system-dependent currency symbol is dangerous. I actually knew people who lost lots of money through that. Especially with US dollar and Euro being close enough that the numbers make sense.

On iOS you typically use a currency code, and the currency code is displayed in a system dependent way. For example, if the currency code is “Hong Kong Dollar”, that will be displayed as “Dollar” in Hong Kong and as “Hong Kong Dollar” everywhere else. Or take the currency symbol “Euro”, which may be displayed as € or Euro, before or after the number, depending on your system.

But just marking something as “Currency” is stupid and dangerous. I think Excel does that.

gnasher729
  • 42,090
  • 4
  • 59
  • 119
11

The question seem to be "why programming languages, frameworks and operating systems support features that are not the best practices for professional developers in large multinational corporations"... and the answer is there are sometimes developers who are not in that category.

If your language only supports enterprise-level features you will not be able to get large adoption. This is indeed concern for languages either targeting "everyone" - like C#, Basic, Java, Python,...

Imagine a regular second day assignment "Alice had 10(units of your local currency) and payed 4 for candy, print how much she had left" - normally it requires knowledge of one basic numeric type (like int) and way to print with possibly default formatting. Now if we require proper currency handling:

  • one must understand difference between general purpose numeric types and monetary once (like float and decimal in C#)
  • must understand complex types to combine amount, currency, and potentially other property as rounding rules to represent "10 units of currency". Probably would need to understand difference between mutable/immutable types.
  • must have some understanding of globalization to know how to pick "local" currency format
  • indeed language will not support inline string literals as those are bad for localization, so some understanding of localization in given framework/language is needed too.
  • since the goal is to be really serious in proper support of localization/globalization good understanding of RTL/LTR languages and mixed strings - clearly such assignment solution must support all sorts of combinations - Hebrew string with Czech koruna for currency is a good start.

This would make writing reasonably correct code that handles money for individual person on they local machine too hard and make language not suitable for beginners and hobbyist.

One writing they first (and possibly last) piece of code to calculate savings growth based on percentage rate is unlikely to ever need that in multi-currency environment.

There are a lot of features that simply should not exist in a language/framework based on same reasoning:

  • string literals can't be used for anything but maybe filed names, should not be printable by itself. Only localizable strings should be allowed
  • Date/time must not exist by itself without explicitly specifying timezone information and rules to apply when timezone information changes
  • no naked numeric types (int, float). Every numeric value must have units of measure and directly or indirectly properties (like rounding rules, overflow rules, precision rules, compatibility with other types for all operations).
  • no "just random numbers generators" - every single one must specify distribution and randomness source at the very least.
  • all math operations must be super hardened. Integer division should only allow precise case - 2/3 should fail. Rounding must have explicit direction always specified. Operations loosing precision must define outcome explicitly inline in the code - even "+ 1" must specify that to avoid getting lost in case of large float numbers.
Alexei Levenkov
  • 312
  • 1
  • 10
  • I think what this shows is that some of these things should either be on a school maths curriculum, or at the very least there should be professional regulation that requires coders to have studied these subjects. – Steve Sep 02 '20 at 12:10
  • 1
    @Steve having defaults that aren't *universally applicable* is still useful. – Caleth Sep 03 '20 at 10:03
  • @Caleth, I agree. But it can be crucial for a coder (and indeed users) to know that certain things are defaults, not immutable axioms. – Steve Sep 03 '20 at 13:02
  • IMO, using a fixed currency (especially if it's displayed unambiguously) is better than using the local one, since it ensures that the value is correct, even if it isn't displayed in the user's preferred representation. (See https://softwareengineering.stackexchange.com/questions/415441/whats-the-use-case-for-formatting-monetary-values-with-a-system-dependent-cur/415447#comment914501_415447 for an example of how things can go wrong.) – Solomon Ucko Sep 04 '20 at 00:10
8

There are a lot of long answers to a simple question here. You ask for a use-case and there's a simple one that I don't think has been mentioned yet: games.

If a game involving money is set in an ambiguous location, why not use the players local currency? It creates a more immersive experience and, as the feature is built into the language, costs very little to add to the game.

Kichi
  • 89
  • 3
  • 1
    I was about to provide this exact counterexample – ScottishTapWater Sep 02 '20 at 12:21
  • 9
    Fair enough, but given that $40,000 buys you a Mercedes, while 40000 Đồng buys a bowl of Pho, I'd say that's a rather poor attempt at improving immersion. You end up with in-game prices being laughably inadequate for some locales – crizzis Sep 02 '20 at 20:40
  • @crizzis You're right, but having the right currency symbol can still be very valuable even if the numbers are all off. Independently of realism, the point of a currency symbol is to *communicate*, and immersion need not be broken by costs being wrong so long as they are *internally consistent*. When I was a kid growing up in Russia, there was a time while I had absolutely no idea what a "$" symbol meant, or how much a car cost. Having a recognizable currency symbol in-game would in many cases just tell people "this is *money*", not "this is [specific currency with contemporaneous value]". – mtraceur Sep 03 '20 at 18:43
  • I was about to give the same answer, but I think the argument is that you wouldn't build such a feature into the OS if it was for such a niche use. There must have been more common LOB scenarios OS developers were thinking of. – Allon Guralnek Sep 04 '20 at 02:04
  • @crizzis Well, for euro and dollar numbers are comparable enough and this covers a lot of gamers and developers already. Yuan has exchange rate of ~1:8 with euro, so just imagine you stepped in a time machine transporting you to 2000 (or 2040 if a game is developed by Chinese and you play in EU). Besides, you still get some "this is money" feeling even if stuff has wacky prices (eg Japan). People mostly don't complain that food or ordinary tools in games costs few gold pieces and is therefore worth hundreds or thousands right now. (see, I didn't put any currency there :P ) – Zizy Archer Sep 04 '20 at 09:28
7

Thirty years ago or more it was probably still reasonable to assume that most computer systems that dealt with financial amounts, did so exclusively in the local currency.

In the English-speaking world and the advanced economies more generally whom computers were built to serve, the local currencies had never changed during the computer era, and many could be traced back centuries, so the idea of a local currency changing was also a fanciful future possibility.

Both Python and VBA can trace their language design back that far. The design of Excel (as @gnasher729 mentions in his answer) goes back even further.

The .NET platform which came together in the late 90s likely inherited that design perspective without further close consideration. It does however also have the option to accept a specific culture as a parameter to the string formatting, which need not be the local culture, so there was some consideration of the potential of handling multiple currencies.

Nowadays, currencies have become as vexed as datetimes, and the only sane option is to store the currency denomination with the amount, in the same way as storing the local timezone or location with the datetime. And god help the developer who has to deal with multiple currencies within the same system, because string formatting will be the least of his concerns.

So it seems to me that the answer to the question, is that the currency formatting functionality of those languages, which bases the format on the system settings, is simply an obsolete feature, and a legacy of decades-old design.

Steve
  • 6,998
  • 1
  • 14
  • 24
  • The change to Euros in Europe happen during the computer era. – Tulains Córdova Sep 01 '20 at 14:39
  • I understand what you’re saying. But it’s not a question of modernity. Working multi-currency (not even speaking about conversion rates) requires skills, and some people out there are already stressed by monetary amounts and are really happy to use a simple software for their day to day personal finance, without adding any complexity that is not of interest for them. I’m not advocating currency- less systems. I just think there is a market for certain products where simplicity wins because in the end, what makes the fortune or the misery of a product is its users happiness ;-) – Christophe Sep 01 '20 at 15:15
  • @Christophe, agreed. I wouldn't want to be the person running "simple" financial software during a currency transition though. – Steve Sep 01 '20 at 15:49
  • 9
    At the time we had a client who had quoted for a large contract in Excel, in the Netherlands, using "Currency", and they saw Dutch Guilders. The customer in Germany opened the document and saw the same numbers but marked as DM. The amount quoted looked about 20% higher than it should have been, so they had no chance to get the contract. – gnasher729 Sep 01 '20 at 22:32
  • 1
    @gnasher729, then they had the luck that both companies used the same translation in Excel. Otherwise, the end-amount of the quote would have been "Unknown formula SOM". – Bart van Ingen Schenau Sep 02 '20 at 05:39
  • @Christophe There's a difference between naivety of implementation and simplicity of UI. You can have a very simple UI with code that can manage different currencies. – Voo Sep 02 '20 at 13:06
  • @Voo Indeed. But you can also have these very terrible ones on the mobile, where the use of a drop-down selection can be very different, and slow you down even if the right choice is already selected. My point, is that If you’re waiter in a restaurant and just want to edit a bill in your local currency on a mobile device using the price on your menu, you do not want an additional field for the currency, because not only you don’t need it but in addition, in the heat of the day, it’s a source of potential error. – Christophe Sep 02 '20 at 13:26
  • @Christophe, I think it's still fair to describe that as a screen design/data entry problem though. I think most of us were thinking about this problem from the point of view of data storage and application logic - about whether the application can intrinsically handle multiple currencies (with an assumption made on certain entry screens that the currency is the local one, which is a fair assumption *most* of the time, but with alternative screens provided that can record a specific currency), or whether the app simply cannot handle multiple currencies at any level. – Steve Sep 02 '20 at 14:02
  • @Christophe The idea isn't that you have to show such a setting prominently in the GUI. You can simply default to the default currency but write your code in such a way as to be flexible. You'd in most situations not want to change that setting in the standard UI but either have it hidden in a setting or preferably get it from the server that stores the bills anyhow. – Voo Sep 02 '20 at 14:19
  • 2
    The UK changed from pounds, shillings and pence to pounds and pence in 1971. This was within the computing era, more than 30 years ago, and in the English speaking world – Dezza Sep 02 '20 at 14:49
  • @Dezza, that's an interesting point. Even most banking operations (as an example of the richest and most financially-oriented corporations) were scarcely computerised at that time, and the actual adoption of decimal currency was announced in 1966 following years of formal consultation, so anyone who had the money to have a computer system dealing with financial amounts in 1971 (i.e. hardly anyone), had definitely been on guard for decimalisation when they wrote it. Also, the currency was not technically changed or revalued (fractions of the existing pound were simply decimalised). – Steve Sep 02 '20 at 15:32
5

TL;DR

Currency formatting has been an OS-level configuration for decades now, and the pre-internet days were a very different beast in terms of the frequency of international transactions and the need for someone in region A to express money using region B's currency.

I suspect the OS-centric currency settings are a relic of the past, kept in either because it simply hasn't been re-evaluated yet, or specifically to provide some backwards compatibility for older tools.

This not not about formatting

While some existing answers provide information and food for thought, I'm also noticing a lack of distinction being made between the choice of currency versus the choice of currency formatting.

While the formatting of currency makes sense to be a local machine decision, the currency symbol itself (not its location - which is also formatting) doesn't quite make sense to be decided by the machine instead of the data source which provided the monetary amount which needs to then be formatted.

It makes no sense for someone to tell me "It costs 100" and for me to then go "oh I prefer that those be 100 yen then!".

I agree on all of the formatting arguments making sense as local machine decisions, but not on the choice of the currency symbol itself, specifically.

What's the benefit of having the OS decide the symbol?

However, currency formatting (and all other numerical formatting) has been an OS-level configuration for decades now, and the pre-internet days were a very different beast in terms of the frequency of international transactions and the need for someone in region A to express money using region B's currency.

There's only one scenario where having this be a local machine decision makes sense:

  • If you're developing software that you intend to sell in regions with a different currency
  • If your customer's ecosystem itself only ever works in its own chosen currency, without ever changing. This could be a single machine, single customer, or a company who operates within one specific currency region.

This is the only case I can think of where this setting is not a problem and actually adds something of value.

In such a case, developers of the software don't need to explicitly account for any future customer's possible currency, in case their software sells well internationally. They wouldn't need to adjust and re-release their code just because their tool is now also being sold in another country.

Instead, they can just represent money numerically and label it as "whatever currency you (the client) uses", and then can blindly trust that the customer's machine presents this currency the way they like to see it.

When you are a customer whose entire ecoysytem (and therefore all input/output of that software) is in a single currency, then monetary values really can be represented as "just a number" to you, since you never need to distinguish between different currencies.

As a basic example, if you need to divide 100 moneys between 5 people, then each person gets 20 moneys. This is correct regardless of what currency you work with, as long as all the values I just used are expressed in the same currency.
However, if one of those people needs to be paid in USD and the others in EUR, then your elegant mathematical and currency-free calculation goes out the window.

With the advent of the internet and international transactions, the whole "single currency ecosystem" idea went straight out the door.

I suspect the OS-centric currency settings are a relic of the past, kept in either because it simply hasn't been re-evaluated yet, or specifically to provide some backwards compatibility for older tools.

Flater
  • 44,596
  • 8
  • 88
  • 122
  • I think not even your basic example is universally correct. I just learnt that a few non-decimal currencies exist even today, for example the Malagasy ariary in Madagascar, which is divided into just 5 sub units, not 100 like Euro or Dollar. If I understand correctly, this means that you cannot divide 1 ariary between 10 people, much like you could not divide 1 euro between 200 people. The type of currency therefore determines which mathematical operations are possible and which are not. – Christian Hackl Sep 03 '20 at 05:46
  • @ChristianHackl: Even if the currency doesn't follow a decimal structure, doesn't mean that I can't express it numerically. A day is not broken in decimal parts but you still understand how much 2.5 days is, because fractionally 0.5 day = 12 hours. You could swing either way with this, either expressing the decimal part as is (.1, .2, .3, .4, .0) and simply have the backend logic account for that (note that formatting isn't something the backend depends on), or you could stick with proper decimals and do (.20, .40, .60, .80, .00). Neither of these contradicts my answer. – Flater Sep 03 '20 at 09:28
  • I would presume the original thinking was something like "most programs only work with one hard-coded currency, or one currency which is assumed to be the current user's/system's currency. If you need to work with multiple currencies, you can store which currency it is out-of-band - incidentally, you can do this by storing the locale string and then pass that along with the number directly into the routine that formats/prints it". – mtraceur Sep 03 '20 at 18:30
  • @mtraceur: I'm not sure how that is functionally different from my answer. – Flater Sep 03 '20 at 22:39
  • It's different because your answer is judging it to be an overall bad design which is outdated and hasn't been reevaluated yet, while my comment shows a perspective on the design which is rather favorable and *timeless* - I could easily see someone using that reasoning as an argument for making or keeping this formatting API design in modern times. – mtraceur Sep 04 '20 at 04:05
0

Handling multiple currencies has been a problem since many centuries (and even millennia). Only the early computing solutions (initially based on US English assumptions) oversimplified the problem.

Multiple currencies will not end, new currencies are still being created (notably virtual currencies, or "community/social" currencies that are being created locally to counter the bad influence of world companies on the local economy).

No unification has been made as it is not realistic for many markets. And let's remember that now all businesses are made in a worldwide context. It makes no sense today to make any business (or even social interactions) with a single currenciy.

You may think that the ISO codes are enough, but this is false, many currencies used today are not encoded just because they are not traded openly on world markets (some local currencies forbid such trades to favor the development of local businesses and activities and more social/balanced terms of exchanges in terms of actual wror or service delivered and the time/efforts spent to resolve real problems).

ISO codes are good for these currently traded currencies in a multilingual worldwide context; they are still poor to modelize the social interactions. Consider each currency to have its own identity and own value (possibly independent and not convertible to other currencies ecept by specific/ad hoc private agreements between their users).

What is important then is to identify the users or communities accepting to trade them. As we identify organizations, there can be millions. A single 3-character code will not represent all organizations of the world. And each organization adopts its own terminology, conventions and languages they understand.

In summary, currencies are not bound to any system (no social interaction) and a system-level currency does not make any sense or to the "open" world market where they "may" be traded (not always the case).

So you need a clear concept where amounts identify both the sums/values, and the identity of the currency. Formatting it is a secondary aspect which is valid only within the scope of communities accepting to trade the currency openly and not just privately (private transactions occur much more often than transactions on open traded markets: you call this the "black market", and governments don't like it, but it has always existed). The only interest of "open" currencies is that governments and banks accept to trade them in a limited market, but they also offer a limited warranty of the value (we know that these warranties are very limited, and in fact they are decreasing: "open" currencies can be seized legally by governments or banks for their own interest without asking to communities; but it is the base of the fiscal systems that governments all depend on, but government should remember that they can do that only because they have a limited trust provided by their population which have only transferred a part of their freedom for making their own trading decisions without permission).

Not all currencies are convertible, as well not all of them are translatable. The formatting options vary also a lot (not all use a decimal system, not all use the same rounding conventions). Each currency identifies its own market and a set of people with their own cultures and conventions, and a set of private transactions between them, and their own rules to govern their emissions (and let's not forget that some "world currencies" are not even tradable openly, they are reserved for some institutions, like the DTC from the World Monetary Fund, and many assets reserved to traders on very risky markets: there are tons of funds, actions, obligations, warrants constantly created, and most of them are unregulated, and most escape the fiscal systems as they are not even located in a clear juridiction; many of them are also abandoned every day and fall to a null value for any other trading, exactly like organizations are being created and die).

All currencies have a limited lifetime, just like organizations, countries, and people in real life, and just like the trust that they give to each other, or revoke at incredible rate. It is then nonsense to speak about a "system currency" unit (introduced in the 1960's but already abandonned today or that should no longer be used as it was a bad design and bad representation of the real world).

Community
  • 1
Philippe Verdy
  • 162
  • 3
  • 2
    So in summary "no good reason" but you felt you needed to use 4k to say it? – tripleee Sep 01 '20 at 17:30
  • Interesting economic thoughts. When a virtual currency makes it way through, people usually find an ISO pseudo-code even if it is not formally defined (see [bitcoin](https://www.coindesk.com/bitcoin-needs-iso-certified-currency-code). Before a currency is well recognized, there are however considerable risks about its value, and more importantly legal implications far beyond registration in an IT system (e.g. countries that forbid transactions in virtual currencies, how to value these currencies for income taxation anyway, how to account for change in value, etc...) – Christophe Sep 01 '20 at 18:40
  • There won't be enough 3-letter ISO codes available for all currencies: many currencies don't have any code. Many currencies are only known and used in specific cultures. Many historic ones have their own subdivisions, many are not convertible in any stable way (given there's no valid market to trade them at predictable price for any kind of transaction between any pair of actors) – Philippe Verdy Sep 01 '20 at 19:21
  • So consider "currencies to be just "products" like apples and pears: an amount along without saying if it designates apples or pears, or litres of water, means nothing. it's just a number with some properties (a precision, and subdivisions that are not necessarily tradable like the full unit and without unambiguous convertibility with the full unit because of rounding rules applied in the community that sponsored the unit) – Philippe Verdy Sep 01 '20 at 19:25
  • Another example: is two half-apples the same value as a single uncut apple? Most people will consider its value is less because the cut apples will loss value must faster than an uncut apple. The same applies to currency subdivisions. So you can trade apples, not half-apples unless you add some value to these half-apples by transforming them into another product traded separately ! – Philippe Verdy Sep 01 '20 at 19:26
  • 1
    @PhilippeVerdy Now if you switch from apples to watermelons, at a market stall where people want to buy some fruit to eat, four quarter watermelons cost a lot more than a single whole one. Because a whole watermelon is too much for most customers. – gnasher729 Sep 01 '20 at 22:35
  • Yes for watermelon, my comment is still valid: you've added a value by providing the service of cutting them, and a packaging, this makes sense if you preserve the freshness of the product (which will still be degraded faster, and so its value is less durable): unsold portions will soon go to the dustbin if there's no way to reuse them for other preparation (e.g. fluit salads, juices, jams). Anyway water melons are fresh products that still degrade rapidly even if uncut (faster than for apples) – Philippe Verdy Sep 02 '20 at 04:13
  • as well, a facial currency amount has other properties, notably its presentation form or its availability, and the management fees to keep them on accounts, and transaction costs for transfers. This form also influences its effective value. As well the amount of transactions plays a large role: it's not so easy to make large transfers or changes of forms, you'll often need a third party to help complete the transaction, and that party will claim its own transaction fees: you need to give trust also to that party, not just to the money transacted, and the efficiency/speed of its execution – Philippe Verdy Sep 02 '20 at 04:17
  • So the facila value (total "owned" amount) is theoretical, just an estimated average. More elements of the currency forms are needed than just identifying the currency with a symbol. Money has lots of properties depending on lots of factors and many decisions made independently by many people – Philippe Verdy Sep 02 '20 at 04:19