Hi Wonseok,
I have entered bug 1878 to track this issue. Please feel free to add
comments.
-Tom
Wonseok Kim wrote:
> Hi Tom,
>
> Comments in line...
>
> On 12/21/06, *Tom Ware* <tom.ware_at_oracle.com
> <mailto:tom.ware_at_oracle.com>> wrote:
>
> Hi Wonseok,
>
> I have been doing some experimentation and have been making some
> progress.
>
> First of all, does Craig's suggestion below solve the issue for you?
> --
> Calendar cal = Calendar.getInstance (TimeZone.getTimeZone
> ("America/Los_Angeles"));
> cal.set(1901, 11, 31, 23, 59, 59);
> --
>
>
> I tried with all Calendar having above timezone(in testcase and
> populator). It solves previously failed tests but it causes failures
> of other tests(time field related). I need to look more into this...
>
> Testcase: testTime took 0.01 sec
> FAILED
> There should be one result
> junit.framework.AssertionFailedError: There should be one result
> at
> oracle.toplink.essentials.testing.tests.ejb.ejbqltesting.JUnitEJBQLDateTimeTestSuite.testTime
> (JUnitEJBQLDateTimeTestSuite.java:75)
> at junit.extensions.TestDecorator.basicRun(TestDecorator.java:22)
> at junit.extensions.TestSetup$1.protect(TestSetup.java:19)
> at junit.extensions.TestSetup.run(TestSetup.java :23)
>
> Testcase: testTimeToTS took 0.004 sec
> FAILED
> There should be one result
> junit.framework.AssertionFailedError: There should be one result
> at
> oracle.toplink.essentials.testing.tests.ejb.ejbqltesting.JUnitEJBQLDateTimeTestSuite.testTimeToTS
> (JUnitEJBQLDateTimeTestSuite.java:87)
> at junit.extensions.TestDecorator.basicRun(TestDecorator.java:22)
> at junit.extensions.TestSetup$1.protect(TestSetup.java:19)
> at junit.extensions.TestSetup.run(TestSetup.java :23)
>
> Testcase: testTimeWithCal took 0.006 sec
> FAILED
> There should be one result
> junit.framework.AssertionFailedError: There should be one result
> at
> oracle.toplink.essentials.testing.tests.ejb.ejbqltesting.JUnitEJBQLDateTimeTestSuite.testTimeWithCal
> (JUnitEJBQLDateTimeTestSuite.java:171)
> at junit.extensions.TestDecorator.basicRun(TestDecorator.java:22)
> at junit.extensions.TestSetup$1.protect(TestSetup.java:19)
> at junit.extensions.TestSetup.run(TestSetup.java :23)
>
>
> I like the idea of making this change better than changing the
> year to
> 1911. You may have to make a similar change where the data gets
> populated.
>
>
> Secondly, my experimentation shows me that there is a potential
> change
> we could make in TopLink Essentials to allow this to
> work. Currently we
> set the date with JDBC's setObject() method. A change to setDate()
> seems to allow this to work when using dates. Perhaps there is a
> bug or
> enhancement we could enter for this.
>
>
> If you can fix this by modifying TopLink, I think it's the best thing.
> Then we don't need to modify tests at all.
>
> Thirdly, I think Craig's suggestion of more explicitly testing
> different timezone's is also a good one. Maybe we should enter and
> enhancement for that.
>
>
> Testing with different timezones looks good to me.
>
> Thanks,
> -Wonseok
>
> I am going to get in touch with the Oracle JDBC folks and get some
> more infomation about this, but wanted to give you an update.
>
> -Tom
>
>
> Craig L Russell wrote:
>
> >Hi Tom,
> >
> >I'm afraid I don't follow.
> >
> >There are 31,536,000,000 milliseconds in one year, which is well past
> >the limit of ~ 2 billion in an integer. So you roll over in integer
> >in a month or two.
> >
> >There is a well-documented boundary case at 1901-12-13 20:45:52,
> >which is the limit for "seconds since the epoch" but this doesn't
> >seem to be what you are testing a boundary case for.
> >
> >To me, there are two issues with the test.
> >
> >1. The result of
> > GregorianCalendar cal = new GregorianCalendar();
> > cal.set(1901, 11, 31, 23, 59, 59);
> >is dependent on which time zone the java vm is running in. In order
> >to make this test run identically in all time zones, you should use
> >the time zone constructor of Calendar, which would be
> > Calendar cal = Calendar.getInstance(TimeZone.getTimeZone
> >("America/Los_Angeles"));
> > cal.set(1901, 11, 31, 23, 59, 59);
> >With this change, the date constructed would be the same no matter
> >where the test happened to run.
> >
> >2. We only randomly test different time zone settings, based on the
> >time zone of whomever happens to run the test. To be sure that all
> >time zones actually work, something like this would be useful:
> >public static String[] getAvailableIDs()
> >
> >Construct different Date instances using Calendars constructed using
> >all the different time zones.
> >for (String s:TimeZone.getAvailableIDs()) {
> > TimeZone tz = TimeZone.getTimeZone(s);
> > Calendar c = Calendar.getInstance(tz);
> > Date d = c.getTime();
> > // test using this Date...
> >}
> >
> >Craig
> >
> >On Dec 19, 2006, at 8:24 AM, Tom Ware wrote:
> >
> >
> >
> >>Hi Wonseok,
> >>
> >> I am doing some investigation and I will let you know what I
> turn up.
> >>
> >> FYI: 1901-12-31 23:59:59.999 is a boundry test case. It just
> >>below the boundry of what dates can be represented with an Integer
> >>value of milliseconds in Java.
> >>
> >>-Tom
> >>
> >>Wonseok Kim wrote:
> >>
> >>
> >>
> >>>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
> <mailto:Michael.Bouschen_at_sun.com>
> >>><mailto: Michael.Bouschen_at_sun.com
> <mailto:Michael.Bouschen_at_sun.com>>> wrote:
> >>>
> >>> Hi Wonseok,
> >>>
> >>> I could successfully run the entity-persistence-tests using a
> >>> 10.2.0.1.0XE jdbc 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.x jdbc drivers?
> >>>
> >>> Regards Michael
> >>>
> >>>
> >>>
> >>>> Hi Tom, Michael
> >>>>
> >>>> This problem occurs only with 10.x drivers(10.1.0.2
> <http://10.1.0.2>
> >>>> < http://10.1.0.2>, 10.1.0.5 <http://10.1.0.5>
> <http://10.1.0.5>, 10.2.0.1 <http://10.2.0.1>
> >>>> < http://10.2.0.1> , 10.2.0.2 <http://10.2.0.2>
> <http://10.2.0.2> ) in my
> >>>> environment, but with 9.x drivers it works fine. Server
> >>>>version(I
> >>>> tried on 9.2.0.1 <http://9.2.0.1> <http://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.x drivers 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
> >>>>
> >>>>
> >>>
> >>>
> >
> >Craig Russell
> >Architect, Sun Java Enterprise System
> http://java.sun.com/products/jdo
> >408 276-5638 mailto: Craig.Russell_at_sun.com
> <mailto:Craig.Russell_at_sun.com>
> >P.S. A good JDO? O, Gasp!
> >
> >
> >
>
>