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 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.
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.
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!
>
>
>