The DataFormatter is not removing the locale when given the format string [$-1010409]General for a number cell. The resulting format String is "General", but is applied too late. In org.apache.poi.ss.usermodel.DataFormatter.getFormat(double, int, String), at the end of the function, createFormat is called. However, if the resulting format is "General" (or I assume "@" also), the logic a couple lines earlier to return generalWholeNumFormat or generalDecimalNumFormat does not apply. If the code were rearranged to apply this check (again?) after createFormat is called, then a valid format could be used. For the Junit, org.apache.poi.ss.usermodel.TestDataFormatter, (I stuck it in testOther), you can add the following to demonstrate this case: assertEquals("63", dfUS.formatRawCellContents(63.0, -1, "[$-1010409]General")); I expect "63". The code outputs "General".
Is the lack of locale removal only affecting the General case, or does it apply to all formats (custom and built in)? (This should help us work out what area to focus on)
(In reply to comment #1) > Is the lack of locale removal only affecting the General case, or does it > apply to all formats (custom and built in)? > > (This should help us work out what area to focus on) General and @ are the ones not working as expected. Other formats, such as ## and 00 are working fine when a locale is present. These 2 fail: assertEquals("63", dfUS.formatRawCellContents(63.0, -1, "[$-1010409]General")); assertEquals("63", dfUS.formatRawCellContents(63.0, -1, "[$-1010409]@")); These 2 are fine: assertEquals("63", dfUS.formatRawCellContents(63.0, -1, "[$-1010409]##")); assertEquals("63", dfUS.formatRawCellContents(63.0, -1, "[$-1010409]00")); I put all 4 formats in Excel 2003, and when saved to CSV, they export as "63".
Fixed in r1349562, and unit tests added based on your supplied example ones, thanks!