[
https://issues.apache.org/jira/browse/PDFBOX-1803?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13896180#comment-13896180
]
Tim Allison commented on PDFBOX-1803:
-------------------------------------
[~zweibieren], thank you for all of your work on date parsing!
This patch does a far better job than I did with my duplicate (PDFBOX-1883) of
dealing with back-compat and the history of the exceptions/return values.
Would it be possible to consider two small mods (first is important, second
isn't):
1) add handling and tests for a string that is made up of only spaces. Current
patch still throws StringIndexOutOfBounds for that case.
2) add a syntactic sugar static isBad(Calendar cal) function (or similar) so
that clients don't have to test for null and test for the magic bad date.
> StringIndexOutOfBound on DateConverter.toCalendar
> -------------------------------------------------
>
> Key: PDFBOX-1803
> URL: https://issues.apache.org/jira/browse/PDFBOX-1803
> Project: PDFBox
> Issue Type: Bug
> Components: PDModel, Utilities
> Affects Versions: 1.8.3
> Reporter: Eric Leleu
> Priority: Minor
> Attachments: PDFBOX-DateConverter-1.8-fred.patch,
> PDFBOX-DateConverter-Trunk-fred.patch, PDFBox-DateConverter-Br18.patch,
> PDFBox-DateConverter-Trunk.patch
>
>
> Some PDF have an empty string as CreationDate & ModDate in the Information
> Dictionary.
> According to the PDF specification, this two element are optional.
> My first fix was to test the null & the empty string in the
> toCalendar(String, String[]) method and I return null if one of the both
> condition is verified.
> But according to a test case(TestDateUtil) a NullPointer is expected on null
> value of text. Can you explain why this behaviour has been adopted?
> To fixe this unexpected exception in my execution path, I have added a test
> on the empty string in the deprecated method toCalendar(String). (Patch in
> attachment)
> I'm waiting your comment before commit this patch (or change it by my first
> implementation)
> BR,
> Eric
--
This message was sent by Atlassian JIRA
(v6.1.5#6160)