I found this problem occurs in Asia/Seoul timezone with 10.x drivers in my
Linux environment. If I use another timezone, it doesn't happen.
I don't know why, but you may reproduce it and report to Oracle driver team.
I don't think this is TopLink problem, it isn't affected by timezone, right?
I also works well with 9.x drivers and on other databases.
So just changing date values will be no harm, Tom could you confirm this?
Thanks,
-Wonseok
On 12/19/06, Michael Bouschen <Michael.Bouschen_at_sun.com> wrote:
>
> Hi Wonseok,
>
> I could successfully run the entity-persistence-tests using a 10.2.0.1.0XEjdbc driver w/o getting the date problem you are facing.
>
> Your changes looks ok to me. However, we should double check that this is
> really an oracle jdbc driver problem. I'm just afraid of changing the test
> case now which might hide the real problem.
>
> Tom,
> do you have some more insights about possible isses with the oracle 10.xjdbc drivers?
>
> Regards Michael
>
> Hi Tom, Michael
>
> This problem occurs only with 10.x drivers(10.1.0.2, 10.1.0.5, 10.2.0.1,
> 10.2.0.2 ) in my environment, but with 9.x drivers it works fine. Server
> version(I tried on 9.2.0.1 and 10.2.0.1-XE) doesn't matter.
>
> I found the date value "1901-12-31 23:59:59.999" is inserted as
> "1902-01-01 00.00.00.999" with 10.x drivers, but not with 9.x drivers.
> But if I change the value to "1911-12-31 23:59:59.999", it is inserted
> correctly with 10.x drivers.
> So I suspect that the very old date value is not handled well with 10.xdrivers in specific timezone.
>
> To avoid this problem, I would like to change date values from "1901-12-31
> 23:59:59.999" to "1911-12-31 23:59:59.999" occuring in DateTimePopulator
> and JUnitEJBQLDateTimeTestSuite. There was no problem in other tests.
> Please review the attached diff.
>
> Thanks,
> -Wonseok
>
>