[
https://issues.apache.org/jira/browse/PDFBOX-1633?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13750547#comment-13750547
]
Tilman Hausherr edited comment on PDFBOX-1633 at 8/26/13 9:04 PM:
------------------------------------------------------------------
Doesn't build:
testDateConverter(org.apache.pdfbox.util.TestDateUtil) Time elapsed: 0.029 sec
<<< FAILURE!
junit.framework.AssertionFailedError: expected:<2007> but was:<-999>
cal = DateConverter.toCalendar(orig);
fails because of an exception. I changed the code to show the exception, this
way one knows which test failed:
java.io.IOException: Error converting date:Tue Aug 21 10:35:22 2007
at
org.apache.pdfbox.util.DateConverter.toCalendar(DateConverter.java:708)
at org.apache.pdfbox.util.TestDateUtil.checkParse(TestDateUtil.java:120)
at
org.apache.pdfbox.util.TestDateUtil.testDateConverter(TestDateUtil.java:143)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:606)
at junit.framework.TestCase.runTest(TestCase.java:168)
at junit.framework.TestCase.runBare(TestCase.java:134)
at junit.framework.TestResult$1.protect(TestResult.java:110)
at junit.framework.TestResult.runProtected(TestResult.java:128)
at junit.framework.TestResult.run(TestResult.java:113)
at junit.framework.TestCase.run(TestCase.java:124)
at junit.framework.TestSuite.runTest(TestSuite.java:232)
at junit.framework.TestSuite.run(TestSuite.java:227)
at junit.framework.TestSuite.runTest(TestSuite.java:232)
at junit.framework.TestSuite.run(TestSuite.java:227)
at
org.junit.internal.runners.JUnit38ClassRunner.run(JUnit38ClassRunner.java:83)
at
org.apache.maven.surefire.junit4.JUnit4TestSet.execute(JUnit4TestSet.java:53)
at
org.apache.maven.surefire.junit4.JUnit4Provider.executeTestSet(JUnit4Provider.java:123)
at
org.apache.maven.surefire.junit4.JUnit4Provider.invoke(JUnit4Provider.java:104)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:606)
at
org.apache.maven.surefire.util.ReflectionUtils.invokeMethodWithArray(ReflectionUtils.java:164)
at
org.apache.maven.surefire.booter.ProviderFactory$ProviderProxy.invoke(ProviderFactory.java:110)
at
org.apache.maven.surefire.booter.SurefireStarter.invokeProvider(SurefireStarter.java:172)
at
org.apache.maven.surefire.booter.SurefireStarter.runSuitesInProcessWhenForked(SurefireStarter.java:104)
at
org.apache.maven.surefire.booter.ForkedBooter.main(ForkedBooter.java:70)
was (Author: tilman):
Doesn't build:
testDateConverter(org.apache.pdfbox.util.TestDateUtil) Time elapsed: 0.029 sec
<<< FAILURE!
junit.framework.AssertionFailedError: expected:<2007> but was:<-999>
cal = DateConverter.toCalendar(orig);
fails because of an exception.
> 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
