Open bigspawn opened 5 hours ago
That's my home currency, funny enough.
This is one of the areas where CLDR intentionally goes against ISO:
The currency decimal place information in CLDR is intended to reflect what is the most common usage in the countries in question, (for generalized usage in most computer applications) and may or may not line up exactly with ISO4217. In many of the cases, the true buying power of a single unit of the currency is so small that you would never see a currency value written with any decimal places, but ISO might still list the currency as a 2 decimal place currency. There are certain specialized places such as banking or stock transactions where you might see the decimals, but for normal usage you would never see them.
https://unicode-org.atlassian.net/jira/software/c/projects/CLDR/issues/CLDR-8790 https://unicode-org.atlassian.net/jira/software/c/projects/CLDR/issues/CLDR-11586
This is also currently documented in the code:
// replaceDigits replaces currency digits with data from CLDR.
//
// CLDR data reflects real life usage more closely, specifying 0 digits
// (instead of 2 in ISO data) for ~14 currencies, such as ALL and RSD.
//
// Note that CLDR does not have data for every currency, in which case
// the original ISO digits are kept.
func replaceDigits(currencies map[string]*currencyInfo, dir string) error {
From a Serbian perspective, both ISO and CLDR views are correct.
On one hand, we officially have 2 decimals in our currency, they are expressed in supermarkets (maxi.rs) and on utility bills (such as electricity), in bank apps. On the other hand, there are no coins smaller than 1 RSD, meaning all cash amounts are rounded, eCommerce sites (see gigatron.rs, ananas.rs) never show decimals, and colloquially they are never talked about. The state bank has repeatedly promised to eliminate them officially, but no movement has happened.
Based on previous links, I don't think CLDR will accept a Jira issue for changing this. I could be persuaded to use the ISO data with enough feedback, but I like the fact that this package currently matches CLDR completely, meaning that it has the same rules as in Windows, Mac OS, packages for other languages, etc. Software generally trusts CLDR over ISO when it comes to defaults.
So while I think that that specifying 2 decimals would be a safer default, I am also fine with keeping it as-is and allowing anyone selling groceries online to manage their own number of decimals explicitly. This is also the case in countries like the US, where USD has 2 decimals but certain prices (bulk items, gasoline) have 3 decimals.
@bigspawn It would be great to know how you came across this problem and what your own needs are.
Thanks for the detailed answer!
For card operations, we receive the amount for RSD with decimal 2 from the provider. Example:
{
"amount": "-2999.22",
"currency": "RSD"
}
I see that the description of the library clearly indicates the use of the CLDR format. My expectations were about ISO. I assume that changing the format to ISO does not break backward compatibility, because it precision gets bigger.
Hi!
Faced with the problem that the value of decimal is incorrect for Serbian dinars.
Problem:
"RSD": {"941", 0}
Valid value:
"RSD": {"941", 2}
Source: https://en.wikipedia.org/wiki/ISO_4217