Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Indian number formatting broken #275

Closed
marschall opened this issue Jan 1, 2019 · 15 comments
Closed

Indian number formatting broken #275

marschall opened this issue Jan 1, 2019 · 15 comments

Comments

@marschall
Copy link
Member

Indian digit grouping is more complex than others

groups the rightmost three digits together (till the hundreds place) and thereafter groups by sets of two digits

This means that what in the US would be formatted as 67,890,000,000,000 will be formatted in India as 6,78,90,00,00,00,000.

Consider the following, failing, test:

    /**
     * Test related to parsing and formatting for India.
     */
    @Test
    public void testRupeeFormatting() {
        BigDecimal amount = new BigDecimal("67890000000000");
        Locale india = new Locale("en, IN");

        MonetaryAmountFormat format = MonetaryFormats.getAmountFormat(india);
        Money money = Money.of(amount, "INR");
        String expectedFormattedString = "INR 6,78,90,00,00,00,000.00";
        assertEquals(format.format(money), expectedFormattedString);
        assertEquals(money, Money.parse(expectedFormattedString, format));
    }

https://en.wikipedia.org/wiki/Decimal_separator#Digit_grouping
https://en.wikipedia.org/wiki/Indian_numbering_system
https://stackoverflow.com/questions/5379231/displaying-currency-in-indian-numbering-format

@stokito
Copy link
Member

stokito commented Jan 1, 2019

As I remember for China is the same

@keilw
Copy link
Member

keilw commented Jan 1, 2019

This was among the original goals of JSR 354. It should have worked at some point, so this is also a blocker before getting the MR out. Added the Unit Test method testRupeeFormatting to MonetaryFormatsTest, currently disabled.

@stokito
Copy link
Member

stokito commented Jan 29, 2019

Parsing of Indian/China numbers was fixed in scope of #193. See a unit test for this MonetaryFormatsTest#testParse_INR_en_IN and AmountNumberTokenTest#testParse_CN.

But I still didn't try to fix formatting of the numbers. I guess this can be done with some pattern but not sure about this.
See a unit test for this MonetaryFormatsTest#ttestFormat_INR_en_IN - commented with //FIXME the correct format.

@keilw
Copy link
Member

keilw commented Feb 27, 2019

Any idea when the rest could be fixed?

@stokito
Copy link
Member

stokito commented Feb 27, 2019

Well, since internally is used regular JDK's DecimalFormat so the solution should be similar.
So I searched https://www.google.com.ua/search?q=java+DecimalFormat+inidan+numbers+10000
and the first SO link:
https://stackoverflow.com/questions/25078259/formatting-numbers-in-java-indian-numbering-system
said that this doesn't supported on JDK level.
We should recheck this - maybe it was fixed latter

@keilw keilw pinned this issue Aug 5, 2019
@keilw
Copy link
Member

keilw commented Aug 11, 2019

This looks like the Original https://stackoverflow.com/questions/5379231/displaying-currency-in-indian-numbering-format

ICU4J already has support based on its own fork of java.text.Format. Since it is rather large (10MB or more) I don't think we should simply use it in Moneta, but try to use those tickets or ICU itself as inspirations for this.

@marschall
Copy link
Member Author

This seems to be the bug in the JDK https://bugs.openjdk.java.net/browse/JDK-4738167

@keilw
Copy link
Member

keilw commented Aug 12, 2019

Do you think they're gonna fix it before the bug turns 20? ;-(

@marschall
Copy link
Member Author

Hope springs eternal

@stokito
Copy link
Member

stokito commented Aug 13, 2019

Not sure why this is critical for JavaMoney. Yes, we can parse those numbers but if such formatting wasn't supported in JDK then probably it's not so important and we can wait for fix from JDK guys. Can any Indian say how much is this important?

@keilw
Copy link
Member

keilw commented Aug 13, 2019

It makes the whole thing inconsistent, if parsing works, but formatting doesn't. Given the JDK has ignored it for nearly 20 years now, we could of course still defer it to a new JSR. @atsticks, @otaviojava WDYT?

@atsticks
Copy link
Member

To make this work a custom grouping must be set on the AmountFormatContext, see AmountFormatParams. When a locale with country IN is set the RI no implicitly corrects the grouping size, if not already set explicitly.

@atsticks
Copy link
Member

According to https://www.thefinancials.com/Default.aspx?SubSectionID=curformat India is the only case. China uses the default formatting as defined by the JDK.

@keilw
Copy link
Member

keilw commented Sep 13, 2019

So is there a workaround or is it too little used to address it?
@atsticks at al, thanks for going over all those, so we can progress with the MR1 as soon as the JCP got back from their OC1 mode.

@keilw
Copy link
Member

keilw commented Sep 13, 2019

So I guess we can also close JavaMoney/jsr354-ri-bp#55

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

4 participants