[
https://issues.apache.org/jira/browse/PDFBOX-1803?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13844288#comment-13844288
]
Fred Hansen commented on PDFBOX-1803:
-------------------------------------
Before rewriting DateConverter I reviewed all the JIRA reports about it.
Several such as PDFBOX-977 and PDFBOX-145 were IOExceptions. This was the
documented response to an invalid date, but the programs had been unprepared to
deal with it. Some of my thinking was along these lines:
{panel:bgColor=#ffd}
- programmers cut corners by failing to read documentation
- dates are important, but if one is invalid the user penalty should not be an
exception that halts processing of the PDF
- an exception is a heavy weight response while a date format error is a
light-weight failure
- how should a program handle a bad date? at best it can leave the date blank
or put in a dummy value
{panel}
So I decided on the dummy value scheme. The program can be written paying no
attention to errors and not failing. The user may see the dummy value, but he
or she is unlikely to confuse that with a "real" creation date. There are no
exceptions to trip up the programmer or prematurely terminate execution. And
yet the bad date can easily be detected and processed, if desired.
> 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.4#6159)
