Bug 52389

Summary: [PATCH] DataFormatter broken for Custom Date Formats
Product: POI Reporter: Jeremy <rpi_alum>
Component: XSSFAssignee: POI Developers List <dev>
Severity: normal    
Priority: P2    
Version: 3.8-dev   
Target Milestone: ---   
Hardware: PC   
OS: All   
Bug Depends on: 52349    
Bug Blocks:    
Attachments: Patch of dataFormatter to ignore AM/PM formats as fractions

Description Jeremy 2011-12-27 17:04:22 UTC
Created attachment 28101 [details]
Patch of dataFormatter to ignore AM/PM formats as fractions

Patch made for POI-52349 breaks custom Date/Time formats when AM/PM is contained in custom format.

Bug found from failure in TIKA's ExcelParserTest junit test case, when using daily builds of both projects.

Patch file contains additional ignore cases specific to AM/PM formats before using the new FratcionFormat() call added during the 52349 patch.   NOTE: This may not be the proper or best method to achieve the fix, although it does appear to solve the problem for the Tika test case.

(See also TIKA-833)
Comment 1 Jeremy 2011-12-27 17:11:44 UTC
A better method may be to check for the precence of the '#/#' or the various valid fraction format strings before calling the FractionFormat() method.  I'm not familiar enough with the valid types of fraction format strings, but do believe most use the # symbol in them.
Comment 2 Nick Burch 2011-12-28 05:03:36 UTC
I think there are two problems:
 * The AM/PM dates aren't being correctly detected as dates
 * Passing an AM/PM into the fraction formatter breaks things

I think we'll need to fix these independently
Comment 3 Nick Burch 2011-12-28 05:30:05 UTC
Ah, I think it was the custom format that was breaking, which we don't currently support

As of r1225098 we should now only be entering the fraction code on #/# or ?/? strings, and not all / ones (as the TEXT function used to do)

I believe this resolves the issue, if so please close this bug and the Tika one!
Comment 4 Jeremy 2011-12-29 13:42:10 UTC
Thanks Nick, That did it!!