[
https://issues.apache.org/jira/browse/PDFBOX-1633?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13750990#comment-13750990
]
Tilman Hausherr commented on PDFBOX-1633:
-----------------------------------------
more tests that fail:
testDateConverter(org.apache.pdfbox.util.TestDateUtil): null
expected:<2013-07-06T17:22:01[-05]:00> but was:<2013-07-06T17:22:01[+01]:00>
testDateConverter(org.apache.pdfbox.util.TestDateUtil): null
expected:<2013-07-06T17:22:01[-05]:00> but was:<2013-07-06T17:22:01[+01]:00>
testDateConverter(org.apache.pdfbox.util.TestDateUtil): null
expected:<2013-07-06T00:00:00[-05]:00> but was:<2013-07-06T00:00:00[+01]:00>
I suspect that all tests after "test cases for all entries on old formats list"
fail.
Having looked at the tests above, the first of the failed tests should probably
be changed to
checkParse(2013, 7, 6, 17, 22, 1, tzH,tzM, "Saturday, 6 Jul 2013 5:22:1 PM");
which works, and all the others similarly with "tzH,tzM".
Suggestion:
- correct all on your side
- run the tests again
- delete the old attachments here
- reupload the two files
I then run the tests again here and tell you if it works.
> 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
