[jira] [Updated] (PDFBOX-1633) DateConverter needs to work

["Fred Hansen (JIRA)" <ji...@apache.org>]

     [ https://issues.apache.org/jira/browse/PDFBOX-1633?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Fred Hansen updated PDFBOX-1633:
--------------------------------

    Attachment:     (was: TestDateUtil.java)
    
> 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
>
>   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