I have just downloaded the latest 2.0 source and run "mvn package". Compiled and tested fine. Then I replaced DateConverter and TestDateUtil. Again, it built and tested just fine.
The date string "Tue Aug 21 10:35:22 2007" should match the last of the alphaStartFormats: "EEEE MMM dd HH:mm:ss yy", // GNU Ghostscript 7.0.7 variant I don't know why it doesn't in your tests. >________________________________ > From: Tilman Hausherr (JIRA) <[email protected]> >To: [email protected] >Sent: Monday, August 26, 2013 5:00 PM >Subject: [jira] [Commented] (PDFBOX-1633) DateConverter needs to work > > > > [ >https://issues.apache.org/jira/browse/PDFBOX-1633?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13750547#comment-13750547 > ] > >Tilman Hausherr commented on PDFBOX-1633: >----------------------------------------- > >Doesn't build: > > >> 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 > > >
