Derby
  1. Derby
  2. DERBY-5414

SysDiagVTIMappingTest.test_5391() failed: java.text.ParseException: Unparseable date: "Thu Sep 15 14:00:16 CEST 2011"

    Details

    • Type: Bug Bug
    • Status: Closed
    • Priority: Major Major
    • Resolution: Fixed
    • Affects Version/s: 10.8.2.2
    • Fix Version/s: 10.8.2.2, 10.9.1.0
    • Component/s: Test
    • Labels:
      None
    • Bug behavior facts:
      Regression Test Failure

      Description

      Seen when testing the 10.8.2.1 release candidate on Windows 7:

      http://dbtg.foundry.sun.com/derby/test/10.8.2.1_RC/logs/jvm1.6/win7/suitesAll/report.txt

      There were 2 errors:
      1) test_5391(org.apache.derbyTesting.functionTests.tests.lang.SysDiagVTIMappingTest)java.text.ParseException: Unparseable date: "Thu Sep 15 14:00:16 CEST 2011"
      at java.text.DateFormat.parse(DateFormat.java:337)
      at org.apache.derbyTesting.functionTests.tests.lang.SysDiagVTIMappingTest.vetTimestamp(SysDiagVTIMappingTest.java:744)
      at org.apache.derbyTesting.functionTests.tests.lang.SysDiagVTIMappingTest.test_5391(SysDiagVTIMappingTest.java:728)
      at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
      at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
      at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
      at org.apache.derbyTesting.junit.BaseTestCase.runBare(BaseTestCase.java:113)
      at junit.extensions.TestDecorator.basicRun(TestDecorator.java:24)
      at junit.extensions.TestSetup$1.protect(TestSetup.java:21)
      at junit.extensions.TestSetup.run(TestSetup.java:25)
      at org.apache.derbyTesting.junit.BaseTestSetup.run(BaseTestSetup.java:57)
      at junit.extensions.TestDecorator.basicRun(TestDecorator.java:24)
      at junit.extensions.TestSetup$1.protect(TestSetup.java:21)
      at junit.extensions.TestSetup.run(TestSetup.java:25)
      at junit.extensions.TestDecorator.basicRun(TestDecorator.java:24)
      at junit.extensions.TestSetup$1.protect(TestSetup.java:21)
      at junit.extensions.TestSetup.run(TestSetup.java:25)
      at junit.extensions.TestDecorator.basicRun(TestDecorator.java:24)
      at junit.extensions.TestSetup$1.protect(TestSetup.java:21)
      at junit.extensions.TestSetup.run(TestSetup.java:25)
      2) test_5391(org.apache.derbyTesting.functionTests.tests.lang.SysDiagVTIMappingTest)java.text.ParseException: Unparseable date: "Thu Sep 15 14:00:16 CEST 2011"
      at java.text.DateFormat.parse(DateFormat.java:337)
      at org.apache.derbyTesting.functionTests.tests.lang.SysDiagVTIMappingTest.vetTimestamp(SysDiagVTIMappingTest.java:744)
      at org.apache.derbyTesting.functionTests.tests.lang.SysDiagVTIMappingTest.test_5391(SysDiagVTIMappingTest.java:728)
      at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
      at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
      at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
      at org.apache.derbyTesting.junit.BaseTestCase.runBare(BaseTestCase.java:113)
      at junit.extensions.TestDecorator.basicRun(TestDecorator.java:24)
      at junit.extensions.TestSetup$1.protect(TestSetup.java:21)
      at junit.extensions.TestSetup.run(TestSetup.java:25)
      at org.apache.derbyTesting.junit.BaseTestSetup.run(BaseTestSetup.java:57)
      at junit.extensions.TestDecorator.basicRun(TestDecorator.java:24)
      at junit.extensions.TestSetup$1.protect(TestSetup.java:21)
      at junit.extensions.TestSetup.run(TestSetup.java:25)
      at junit.extensions.TestDecorator.basicRun(TestDecorator.java:24)
      at junit.extensions.TestSetup$1.protect(TestSetup.java:21)
      at junit.extensions.TestSetup.run(TestSetup.java:25)
      at org.apache.derbyTesting.junit.BaseTestSetup.run(BaseTestSetup.java:57)
      at junit.extensions.TestDecorator.basicRun(TestDecorator.java:24)
      at junit.extensions.TestSetup$1.protect(TestSetup.java:21)
      at junit.extensions.TestSetup.run(TestSetup.java:25)
      at junit.extensions.TestDecorator.basicRun(TestDecorator.java:24)
      at junit.extensions.TestSetup$1.protect(TestSetup.java:21)
      at junit.extensions.TestSetup.run(TestSetup.java:25)
      at junit.extensions.TestDecorator.basicRun(TestDecorator.java:24)
      at junit.extensions.TestSetup$1.protect(TestSetup.java:21)
      at junit.extensions.TestSetup.run(TestSetup.java:25)

      1. d5414.diff
        3 kB
        Knut Anders Hatlen

        Issue Links

          Activity

          Hide
          Knut Anders Hatlen added a comment -

          I'm able to reproduce these failures on Solaris too when I run the test in a non-English locale (for example: nn_NO.UTF-8, de_DE.UTF-8, ja_JP.eucJP).

          The problem seems to be that a SimpleDateFormat instance is used to parse the time strings, and that instance uses the default system locale. The time strings are however created by java.util.Date.toString(), which always creates the time strings in the US locale.

          The attached patch fixes the failures by creating the SimpleDateFormat instances with locale explicitly set to Locale.US.

          Another question is of course whether it is OK that the timestamp is always in English, or if it should be localized, or perhaps printed in some standard format that doesn't use names of days/months at all. But to fix the immediate problem (that the test and the VTI don't manage to parse the dates), I think the patch is sufficient.

          Show
          Knut Anders Hatlen added a comment - I'm able to reproduce these failures on Solaris too when I run the test in a non-English locale (for example: nn_NO.UTF-8, de_DE.UTF-8, ja_JP.eucJP). The problem seems to be that a SimpleDateFormat instance is used to parse the time strings, and that instance uses the default system locale. The time strings are however created by java.util.Date.toString(), which always creates the time strings in the US locale. The attached patch fixes the failures by creating the SimpleDateFormat instances with locale explicitly set to Locale.US. Another question is of course whether it is OK that the timestamp is always in English, or if it should be localized, or perhaps printed in some standard format that doesn't use names of days/months at all. But to fix the immediate problem (that the test and the VTI don't manage to parse the dates), I think the patch is sufficient.
          Hide
          Dag H. Wanvik added a comment -

          I guess I would expect the time stamp from a call to SELECT * FROM NEW org.apache.derby.diag.StatementDuration to be localized. Or?

          Show
          Dag H. Wanvik added a comment - I guess I would expect the time stamp from a call to SELECT * FROM NEW org.apache.derby.diag.StatementDuration to be localized. Or?
          Hide
          Rick Hillegas added a comment -

          Much of the output to derby.log is localized so it may make sense to localize the timestamps too. However, that may cause backward compatibility problems for users and for Derby itself. DERBY-5391 is evidence that we may not have regression tests to catch the backward compatibility problems which this may cause Derby.

          The proposed fix looks good.

          Note that these diagnostic VTIs can be used to read derby.log files created by other databases in other locales. If we localize the timestamps printed to derby.log, then we will have to make StatementDuration smart enough to figure out the locale used by a foreign derby.log. Note that the TS columns of the two diagnostic VTIs are typed as VARCHAR(29), not as TIMESTAMP. That lets those columns be agnostic about the foreign locale. The timestamp arithmetic for the DURATION column of StatementDuration would have to be smarter though.

          Show
          Rick Hillegas added a comment - Much of the output to derby.log is localized so it may make sense to localize the timestamps too. However, that may cause backward compatibility problems for users and for Derby itself. DERBY-5391 is evidence that we may not have regression tests to catch the backward compatibility problems which this may cause Derby. The proposed fix looks good. Note that these diagnostic VTIs can be used to read derby.log files created by other databases in other locales. If we localize the timestamps printed to derby.log, then we will have to make StatementDuration smart enough to figure out the locale used by a foreign derby.log. Note that the TS columns of the two diagnostic VTIs are typed as VARCHAR(29), not as TIMESTAMP. That lets those columns be agnostic about the foreign locale. The timestamp arithmetic for the DURATION column of StatementDuration would have to be smarter though.
          Hide
          Knut Anders Hatlen added a comment -

          Thanks, Dag and Rick, for looking at the patch.

          Committed revision 1171672.
          Backported to 10.8 and committed revision 1171678.

          I'm marking this issue as resolved. If we want to change the format of the timestamp, I think we should explore that in a different issue. In such case, my vote would probably go to a format that's easy to parse and that's the same in all locales (for example 2011-09-15 19:16:23 + timezone). Or maybe switch to a standard logging API that makes it possible to access the log programmatically.

          Show
          Knut Anders Hatlen added a comment - Thanks, Dag and Rick, for looking at the patch. Committed revision 1171672. Backported to 10.8 and committed revision 1171678. I'm marking this issue as resolved. If we want to change the format of the timestamp, I think we should explore that in a different issue. In such case, my vote would probably go to a format that's easy to parse and that's the same in all locales (for example 2011-09-15 19:16:23 + timezone). Or maybe switch to a standard logging API that makes it possible to access the log programmatically.

            People

            • Assignee:
              Knut Anders Hatlen
              Reporter:
              Knut Anders Hatlen
            • Votes:
              0 Vote for this issue
              Watchers:
              0 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved:

                Development