Bug 52389 - [PATCH] DataFormatter broken for Custom Date Formats
Summary: [PATCH] DataFormatter broken for Custom Date Formats
Status: RESOLVED FIXED
Alias: None
Product: POI
Classification: Unclassified
Component: XSSF (show other bugs)
Version: 3.8-dev
Hardware: PC All
: P2 normal (vote)
Target Milestone: ---
Assignee: POI Developers List
URL:
Keywords:
Depends on: 52349
Blocks:
  Show dependency tree
 
Reported: 2011-12-27 17:04 UTC by Jeremy
Modified: 2011-12-29 13:42 UTC (History)
0 users



Attachments
Patch of dataFormatter to ignore AM/PM formats as fractions (765 bytes, application/octet-stream)
2011-12-27 17:04 UTC, Jeremy
Details

Note You need to log in before you can comment on or make changes to this bug.
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!!