[
https://issues.apache.org/jira/browse/PDFBOX-1633?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13751271#comment-13751271
]
Tilman Hausherr commented on PDFBOX-1633:
-----------------------------------------
There's a preflight test (I tried to build the whole "pdfbox reactor" project)
that fails (NPE) because of another bug in
Calendar toCalendar(COSString text)
The javadoc reads "The Calendar that this string represents. Or null if text
was null."
So please add
if (text == null)
return null;
at the beginning of the function.
testAllInfoSynchronized() also fails. The reason is that the date passed in
dico.setCreationDate() and dico.setModificationDate() is stored as a string in
COSDictionary.setDate() by using DateConverter.toString(), but your version
isn't using the DST_OFFSET. The old version did, but using that one instead
results in the tests failing again. I suspect you'll have to handle the DST and
adjust all the tests.
here's an output I inserted into
apache\pdfbox\preflight\metadata\SynchronizedMetaDataValidation.java#analyzeCreationDateProperty():
DateConverter.toISO8601(xmpCreationDate): 2013-08-27T15:50:27+02:00
DateConverter.toISO8601(creationDate): 2013-08-27T15:50:27+01:00
> DateConverter needs to work
> ---------------------------
>
> Key: PDFBOX-1633
> URL: https://issues.apache.org/jira/browse/PDFBOX-1633
> Project: PDFBox
> Issue Type: Bug
> Components: Utilities
> Affects Versions: 1.8.2
> Environment: all os and java platforms
> Reporter: Fred Hansen
> Fix For: 1.8.3, 2.0.0
>
> Attachments: DateConverter.java, TestDateUtil.java
>
> Original Estimate: 1h
> Remaining Estimate: 1h
>
> Most of the tests for org/apache/pdfbox/util/DateConverter.java in
> src/test/java/org/apache/pdfbox/util/TestDateUtil.java have been commented
> out. DateConverter was broken.
> The attached patch fixes the problems. Extensive comments document the
> problems. Here's a copy:
> /* the former version of DateConverter had these bugs:
> * - In toISO8601 the conversion from millis to minutes was with 1000/1000;
> * should have been 1000/60.
> * - PDFBox-402 was not completely implemented. The calendar fields in the
> * POTENTIAL_FORMATS are shared among threads. Hence we must create new
> * SimpleThreadFormats for each test. (Or synchronize somehow).
> * - Some formats with hh did not have an a field. I changed them to HH.
> *
> * these questionable features:
> * - A timezone with neither plus sign nor minus is assumed to be minus.
> * This seems wrong, but I have not changed it.
> * - toCalendar() returned a value in the default Locale.
> * PDF files do not have locales (I think) and even if they do
> * there is no reason to assume the Java default.
> * I have switched to Locale.ENGLISH which was already assumed
> * in the date formats and toString.
> *
> * and these infelicities:
> * - Constants 60 and 1000 appeared.
> * - zeroAppend was not used where applicable.
> * In one case it was inapplicable only because TimeZone.getOffset
> * was suspected of returning a long. It does not.
> * - Manually computed constants were used to in date.substring
> * thus reducing flexibility and maintainability.
> * - The TimeZone name reported by toCalendar was always "Unknown"
> * It is easy enough to compute a name.
> * - Time zones were not accepted with most of the alternate parsing
> formats.
> * The new code allows a timezone after any format.
> */
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
