Hi Tom,
Comments in line...
On 12/21/06, Tom Ware <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>> 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>, 10.1.0.5 <http://10.1.0.5>, 10.2.0.1
> >>>> <http://10.2.0.1> , 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> 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
> >P.S. A good JDO? O, Gasp!
> >
> >
> >
>