Mailing-List: contact dev-help@harmony.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@harmony.apache.org
Received-SPF: pass (nike.apache.org: domain of junjie0122@gmail.com designates
 209.85.146.178 as permitted sender)
DomainKey-Signature: a=rsa-sha1; c=nofws;
        d=gmail.com; s=gamma;
        h=mime-version:in-reply-to:references:date:message-id:subject:from:to
         :content-type;
        b=vhxOrLP9PyZXgHfO5gn5s+0sJ5BovVS8JvZtCUSyaV2+WwBT/3fIkDA+sK02qAKW5H
         Tw5gwJDtbR6GltcWM/6HPiiYNDmYVLLwekxSpecKYcwYzNxpwqdHHgAbB2phrIo0T/GH
         sjHKBjxcv1Ox5S/uKJxGBJgh6Y6hPmxBhjkXQ=
MIME-Version: 1.0
In-Reply-To: <4A0C40E3.6050708@googlemail.com>
References: <1853555057.1242145425682.JavaMail.jira@brutus>
	 <4A0C40E3.6050708@googlemail.com>
Date: Fri, 15 May 2009 16:04:45 +0800
Message-ID: <c8963150905150104g2e0cd5aai530a91488d6bfbaf@mail.gmail.com>
Subject: Re: [jira] Created: (HARMONY-6207) [classlib][text]
	SimpleDateFormatTest.test_parseLjava_lang_StringLjava_text_ParsePosition
	would fail
From: Jim Yu <junjie0122@gmail.com>
To: dev@harmony.apache.org
Content-Type: multipart/alternative; boundary=0016e64b06d8c912ed0469eee599

--0016e64b06d8c912ed0469eee599
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit

Hi Oli,

Thanks for your attention on this issue. My explanation as below. I hope it
could help explain the reason:-)

2009/5/15 Oliver Deakin <oliver.deakin@googlemail.com>

> Hi Jim,
>
> I just had a look at this JIRA and had a question about it. It sounds from
> your description that we are seeing a difference between ICU's and Harmony's
> implementation of some Calendar related classes. This seems to me like a bug
> in either our code or ICU's and I wasn't sure that fixing the tests to pass
> was the right thing to do


The failing testcase is for SimpleDateFormat class but there is no bug of
this class for this testcase. The reason of why the testcase failed is that
we used getTime method of GregorianCalendar instance to create a Date
instance as the expected value. However, there is a non-bug behavior
difference between GregorianCalendar instances of Harmony and ICU.(ICU
complies with newer version of CLDR while Harmony complies with older one I
guess. Please correct me if there is something incorrect) So when the
testcase want to assert that the expected Date instance created by Harmony
equals the result Date instance created by ICU is true, it failed. In a
word, the testcase discovered a non-bug difference of GregorianCalendar
between Harmony and ICU other than a bug of SimpleDateFormat class.


> here. My thoughts were that we need to do one of:
> - raise a bug with ICU and fix the tests for now.
> - fix a bug in our GregorianCalendar class.
> - delegate from our GregorianCalendar class to ICU's version (why don't we
> do this already?).
>
> I may be missing something, so I thought I'd ask - it just seems that there
> is a bug/discrepancy here somewhere that needs to be fixed. I guess my
> question is: why is this a fix to the tests and not the code? :)


Our implementation of SimpleDateFormat class is correct for this testcase,
so we don't need to make a fix to the code. BTW, to delegate from our
GregorianCalendar class to ICU's version is a work we need to do. (Maybe
there is a lot work to do as we need to delegate Calendar class as well and
might need to update the testcase for them) But in this case, it is not
necessary as we can use Date instance directly to create expected value
other than via creating a GregorianCalendar instance first and calling
getTime after that.


>
>
> Regards,
> Oliver
>
>
> Jim Yu (JIRA) wrote:
>
>> [classlib][text]
>> SimpleDateFormatTest.test_parseLjava_lang_StringLjava_text_ParsePosition
>> would fail
>>
>> ----------------------------------------------------------------------------------------------------
>>
>>                 Key: HARMONY-6207
>>                 URL: https://issues.apache.org/jira/browse/HARMONY-6207
>>             Project: Harmony
>>          Issue Type: Test
>>          Components: Classlib
>>    Affects Versions: 5.0M9
>>            Reporter: Jim Yu
>>             Fix For: 5.0M10
>>
>>
>> Currently, the testcase
>> SimpleDateFormatTest.test_parseLjava_lang_StringLjava_text_ParsePosition
>> would fail. I've investigated the root cause of this failure and found the
>> main reason is that the GregorianCalendar class used in the testcase is
>> implemented by Harmony itself not delegating to ICU. So when we call getTime
>> of GregorianCalendar to get an Date instance as the expected value, it would
>> not equal to the one created by ICU as the result. E.g. the following
>> testcase [1] would fail while [2] can pass. So I use Date instances directly
>> for these failing ones in my patch. [1] test.parse("yyy", "99", new
>> GregorianCalendar(99, Calendar.JANUARY, 1)
>>                .getTime(), 0, 2);
>> [2] test.parse("yyy", "99", new com.ibm.icu.util.GregorianCalendar(99,
>> Calendar.JANUARY, 1)
>>                .getTime(), 0, 2);
>>
>>
>>
>>
>
> --
> Oliver Deakin
> Unless stated otherwise above:
> IBM United Kingdom Limited - Registered in England and Wales with number
> 741598. Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire
> PO6 3AU
>
>


-- 
Best Regards,
Jim, Jun Jie Yu

--0016e64b06d8c912ed0469eee599--