Currency patterns and fraction information

[Philippe Verdy]

But there's a caveat: the precision of currency amounts is varaible
depending on usage or currency form.
- There's a legal precision used for accounting (bank accounts, billing,
transfers, checks, credit card), usually 2 decimals in most countries. It
is used for electronic payments.
- There's a legal precision for the usable coins (soon, some countries will
abandon the physical money for only electronic currencies, that precision
is lower.
- There's a precision (sometimes legal) for currency conversion (e.g. 6
significant digits for converting former currencies to a new one, like the
transition to the Euro)
- There's a variable precision for pricing (notably price per unit) : oil,
phone fees per minute which is often higher. As long as the traded things
are not cumulated on a legal bill, the precision is kept (the small
differences are then discarded and not reported in the legal accounting
records, only the amount that will be effectively payed/transfered matters,
and it is rounded; intermediate amounts may also be rounded, such as when
computing applicable taxes).
- For some procedures such as fiscal declarations, it is often requested to
round the amounts or discard decimals (differences are "offered' by the
administration and not taxable), simply because it avoids handling errors
(such as forgetting to input a decimal separator, causing taxes to be
computed on amounts 100 times higher than expected : recovering these
errors costs much more than offering these small fiscal exemptions)

For CLDR data we should limit ourself to only two kind of usage :
- electronic money transfers and legal accounting
- physical legal currency (cash)

2014-11-09 20:01 GMT+01:00 Isaac Jurado <isaac.jurado at roiback.com>:

> On Fri, Nov 7, 2014 at 7:07 PM, John Emmons <emmo at us.ibm.com> wrote:
> >
> > Isaac, the reason is that the currency pattern can more generally
> > apply to ANY currency, not just the one that is most commonly used in
> > the country.  For example, in the Japanese locale, I have the default
> > currency pattern of "¤#,##0.00" which would apply as "€1,234.56" for
> > euros, or "¥1,235" for yen.
>
> I understand.  Following Mr. Davis' suggestion, I've been reviewing the
> ICU code and I can see how currency data overrides the pattern.  If I
> was not mistaken, the bulk of the logic is implemented within the
> DecimalFormat class:
>
>
> http://source.icu-project.org/repos/icu/icu/tags/release-52-1/source/i18n/decimfmt.cpp
>
> When using the ".setCurrency()" method, the currency pattern is applied,
> but then the MaxFractionDigits and MinFractionDigits are overriden by
> currency data.  However, when only ".applyPattern()" is used, the
> fraction digit bounds are those from the given pattern.
>
> Therefore, currency data can still be programatically overriden by a
> call to ".applyPattern()" after calling ".setCurrency()".  This
> particular scenario has been trigerring a sort of inconsistency alarm in
> my personal reasoning, hence the initial motivation of my question.
>
> In the end, I drew the following conclusions:
>
>   1. By default, currency data completely overrides currency pattern in
>      terms of number of decimal/fraction digits (as Mr. Davis wrote).
>
>   2. Nevertheless, libraries still offer ultimate flexibility so a
>      pattern can override currency data, and this should be interpreted
>      as a feature, not a bug
>
> For the record, my original intention is to patch the Python Babel [1]
> package in order to comply with currency data obtained from CLDR.
>
> Thank you both Mr. Emmons and Mr. Davis for your answers.
>
> Kind regards.
>
> [1] http://babel.pocoo.org/
>
> --
> Isaac Jurado
>
> _______________________________________________
> CLDR-Users mailing list
> CLDR-Users at unicode.org
> http://unicode.org/mailman/listinfo/cldr-users
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://unicode.org/pipermail/cldr-users/attachments/20141110/638bf498/attachment.html>