|Summary:||[PATCH] DataFormatter broken for Custom Date Formats|
|Component:||XSSF||Assignee:||POI Developers List <dev>|
|Bug Depends on:||52349|
|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!!