Thread: Failing test in org.postgresql.test.jdbc2.DateTest
Hi all,
I have just pulled out the source from CVS and run the build and test
and found a failure in the class noted in the subject. Specifically the
test that fails is:
79 public void testSetDate() throws SQLException
80 {
...
111 ps.setObject(1, "1969-04-3", java.sql.Types.DATE);
112 assertEquals(1, ps.executeUpdate());
...
120 ps.setObject(1, java.sql.Date.valueOf("1912-5-1"),
java.sql.Types.DATE);
121 assertEquals(1, ps.executeUpdate());
...
This only fails in my JDK 1.6 - it passes in 1.5. Looking at the
java.sql.Date in the two source jars I have it's easy to see that the
valueOf method has been completely rewritten in 1.6 (well, at least
1.6.0_21 possibly earlier). Having looked at the API documentation has
remained unchanged in 1.3, 1.4, 1.5 and 1.6 (1.2 I couldn't find by
guessing) and reads:
* @param s a <code>String</code> object representing a date in
* in the format "yyyy-mm-dd"
So it appears that the method now implements the API largely correctly,
however as you can see above a single digit date is still accepted.
Given that the API seems unchanged for so long, I'd recommend changing
the tests to reflect the API.
I've attached a patch to do just that and it's been tested with the
following JDKs:
1.4.2_19
1.5.0_22
1.6.0_21
Regards,
--
Mike Fowler
Registered Linux user: 379787
Attachment
On 23/02/11 16:42, I wrote: > > I've attached a patch to do just that and it's been tested with the > following JDKs: > > 1.4.2_19 > 1.5.0_22 > 1.6.0_21 > > Regards, > Oops, hold the phone. The test still broke on 1.6 but I didn't notice the error as the "build succeeded". The year value 23456 causes the test to fail as the maximum year in java.sql.date is 9999. However, when I change the year to 3456 the test fails: [junit] expected:<3456-01-01> but was:<456-01-01> I'll supply a patch that fixes this once I figure out what's up... Regards, -- Mike Fowler Registered Linux user: 379787
On 23/02/11 18:30, Mike Fowler wrote:
> On 23/02/11 16:42, I wrote:
>>
>> I've attached a patch to do just that and it's been tested with the
>> following JDKs:
>>
>> 1.4.2_19
>> 1.5.0_22
>> 1.6.0_21
>>
>> Regards,
>>
> Oops, hold the phone. The test still broke on 1.6 but I didn't notice
> the error as the "build succeeded". The year value 23456 causes the
> test to fail as the maximum year in java.sql.date is 9999. However,
> when I change the year to 3456 the test fails:
>
> [junit] expected:<3456-01-01> but was:<456-01-01>
Turns out there was another place where a date was being set to
23456-01-01, which was misinterpreted by the 1.6 java.sql.Date. Attached
is the patch that brings all the date tests in line with the published
API. This has been tested on the three JDKs as noted above, and for all
three the test output is:
runtest:
[mkdir] Created dir: /home/mike/oss/pgjdbc/build/testresults
[junit] Testsuite: org.postgresql.test.jdbc2.Jdbc2TestSuite
[junit] Tests run: 293, Failures: 0, Errors: 0, Time elapsed:
61.521 sec
[junit]
[junit] Testsuite: org.postgresql.test.jdbc2.optional.OptionalTestSuite
[junit] Tests run: 40, Failures: 0, Errors: 0, Time elapsed: 3.564 sec
[junit]
[junit] Testsuite: org.postgresql.test.jdbc3.Jdbc3TestSuite
[junit] Tests run: 66, Failures: 0, Errors: 0, Time elapsed: 5.959 sec
[junit]
[junit] Testsuite: org.postgresql.test.xa.XATestSuite
[junit] Tests run: 0, Failures: 0, Errors: 0, Time elapsed: 0.072 sec
[junit]
[junit] ------------- Standard Output ---------------
[junit] Skipping XA tests because max_prepared_transactions = 0.
[junit] ------------- ---------------- ---------------
Regards,
--
Mike Fowler
Registered Linux user: 379787
Attachment
On 02/23/2011 11:42 AM, Mike Fowler wrote:
> Hi all,
>
> I have just pulled out the source from CVS and run the build and test and
> found a failure in the class noted in the subject. Specifically the test that
> fails is:
>
> 79 public void testSetDate() throws SQLException
> 80 {
> ...
> 111 ps.setObject(1, "1969-04-3", java.sql.Types.DATE);
> 112 assertEquals(1, ps.executeUpdate());
> ...
> 120 ps.setObject(1, java.sql.Date.valueOf("1912-5-1"), java.sql.Types.DATE);
> 121 assertEquals(1, ps.executeUpdate());
> ...
>
> This only fails in my JDK 1.6 - it passes in 1.5. Looking at the java.sql.Date
> in the two source jars I have it's easy to see that the valueOf method has
> been completely rewritten in 1.6 (well, at least 1.6.0_21 possibly earlier).
> Having looked at the API documentation has remained unchanged in 1.3, 1.4, 1.5
> and 1.6 (1.2 I couldn't find by guessing) and reads:
>
> * @param s a <code>String</code> object representing a date in
> * in the format "yyyy-mm-dd"
The Java 7 docs say:
"s - a String object representing a date in in the format "yyyy-[m]m-[d]d".
The leading zero for mm and dd may also be omitted."
http://download.oracle.com/javase/7/docs/api/java/sql/Date.html
So the java.sql.Date does accept single-digit month and day, at least for Java 7.
All the work you did to reject single-digit month and day are not correct, if
that's what you did.
--
Lew
Honi soit qui mal y pense.
On 28/02/11 12:56, Lew wrote: > On 02/23/2011 11:42 AM, Mike Fowler wrote: >> >> * @param s a <code>String</code> object representing a date in >> * in the format "yyyy-mm-dd" > > The Java 7 docs say: > "s - a String object representing a date in in the format > "yyyy-[m]m-[d]d". The leading zero for mm and dd may also be omitted." > http://download.oracle.com/javase/7/docs/api/java/sql/Date.html > > So the java.sql.Date does accept single-digit month and day, at least > for Java 7. > > All the work you did to reject single-digit month and day are not > correct, if that's what you did. > It's not correct for Java 7 - but that isn't even out yet. I don't think it's wise to have tests that break in 1.6 just because the API will change in the not so distant future. Personally I think we should test handling of the 1.7 API separately once it's available. Regards, -- Mike Fowler Registered Linux user: 379787
On Mon, 28 Feb 2011, Mike Fowler wrote: > On 23/02/11 18:30, Mike Fowler wrote: >> On 23/02/11 16:42, I wrote: >>> >>> I've attached a patch to do just that and it's been tested with the >>> following JDKs: >>> >>> 1.4.2_19 >>> 1.5.0_22 >>> 1.6.0_21 >>> >>> Regards, >>> >> Oops, hold the phone. The test still broke on 1.6 but I didn't notice the >> error as the "build succeeded". The year value 23456 causes the test to >> fail as the maximum year in java.sql.date is 9999. However, when I change >> the year to 3456 the test fails: >> >> [junit] expected:<3456-01-01> but was:<456-01-01> > > Turns out there was another place where a date was being set to 23456-01-01, > which was misinterpreted by the 1.6 java.sql.Date. Attached is the patch that > brings all the date tests in line with the published API. This has been > tested on the three JDKs as noted above, and for all three the test output > is: This changed somewhere in the 1.6 release because the 1.6.0_11 version I have here doesn't have any problem with the original code, but clearly our tests must work with the latest JVM. I've applied your patch to 8.2 and up in CVS. Thanks, Kris Jurka