From: Craig L Russell <Craig.Russell_at_Sun.COM>
Date: Tue, 19 Dec 2006 11:02:55 -0800

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!