You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@pdfbox.apache.org by "Tilman Hausherr (JIRA)" <ji...@apache.org> on 2013/08/26 23:00:52 UTC
[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
Re: [jira] [Commented] (PDFBOX-1633) DateConverter needs to work
Posted by Fred Hansen <zw...@yahoo.com>.
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) <ji...@apache.org>
>To: dev@pdfbox.apache.org
>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
>
>
>