Mailing-List: contact dev-help@harmony.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@harmony.apache.org
Received-SPF: pass (athena.apache.org: domain of wuyuehao@gmail.com designates
 209.85.216.183 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:content-transfer-encoding;
        b=NXQB31e1SgzYF2LcXTDTP7ynA8nCWurhksJioLFiEb509d7Ypof/DnhypYYWN+XoRV
         y+bYWrJfr1moqtNIkLzOS2IcHzw8mzYcBzaRhw8JkEVdUjKl8DwezWuCQaBoxzCH5PSF
         bFdOCj+0J9HdwFynsfN03jRn7Fx/u7t60elQM=
MIME-Version: 1.0
In-Reply-To: <4B30733A.9040903@gmail.com>
References: <579272672.1261378938115.JavaMail.jira@brutus>
	 <1512608704.1261451778137.JavaMail.jira@brutus>
	 <4d9fb1a00912212237n2cd6cc16m2b231a46ebdb5d00@mail.gmail.com>
	 <4B30733A.9040903@gmail.com>
Date: Tue, 22 Dec 2009 15:57:01 +0800
Message-ID: <211709bc0912212357u76f2dce4i9ff46fcec35ff9c7@mail.gmail.com>
Subject: Re: [jira] Commented: (HARMONY-6410) [classlib][luni] a bug found in
	java.util.TimeZone#getDSTSavings()and #getDisplayName(daylight,style,locale)
From: Tony Wu <wuyuehao@gmail.com>
To: dev@harmony.apache.org
Content-Type: text/plain; charset=GB2312
Content-Transfer-Encoding: quoted-printable

I think the Olson defines the time zone data rather than the localized
display name.  both ICU and Jdk spec don't mention the detail of the
localized string.

but according to the spec of getDisplayName.
"Returns a name of this time zone suitable for presentation to the
user in the specified locale. If the display name is not available for
the locale, then this method returns a string in the normalized custom
ID format. "

I think ICU has gone further here.

On Tue, Dec 22, 2009 at 3:20 PM, Regis <xu.regis@gmail.com> wrote:
> On 2009-12-22 14:37, Ray Chen wrote:
>>
>> Hi,
>> I think it's a very interesting problem. I did a google search and
>> found that seems sun's implementation according to the "tz database"
>> also called "Olson database" (you can refer to [1]).
>>
>> [1]http://en.wikipedia.org/wiki/Zoneinfo
>>
>> Besides, sun offering a tool named "TZUpdater" to update the time zone
>> info in JREs (Maybe harnony should have one too :) ).
>>
>> But I don't know what database harmony is using.
>>
>
> Harmony is using icu4j as locale data provider, I think. And icu4j also u=
ses
> "Olson Time Zone Database" [1], not sure why they got different results,
> maybe different versions of data?
>
> [1] http://icu-project.org/download/icutzu.html
>
>> On Tue, Dec 22, 2009 at 11:16 AM, Nathan Beyer (JIRA)<jira@apache.org>
>>  wrote:
>>>
>>>    [
>>> https://issues.apache.org/jira/browse/HARMONY-6410?page=3Dcom.atlassian=
.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=3D1279=
3477#action_12793477
>>> ]
>>>
>>> Nathan Beyer commented on HARMONY-6410:
>>> ---------------------------------------
>>>
>>> Note - Time zone information and display names are not guaranteed to be
>>> consistent across JREs. Time zone information will depend upon several
>>> factors - the version of the JRE being used, the version of the time zo=
ne
>>> info database being used and other factors. The display names are
>>> localization details.
>>>
>>> Can you define what Sun JDK was used in this test? What version of the
>>> zoneinfo database is used?
>>>
>>> What version of Harmony is used?
>>>
>>>> [classlib][luni] a bug found in java.util.TimeZone#getDSTSavings()and
>>>> #getDisplayName(daylight,style,locale)
>>>>
>>>> ----------------------------------------------------------------------=
--------------------------------------
>>>>
>>>>                 Key: HARMONY-6410
>>>>                 URL: https://issues.apache.org/jira/browse/HARMONY-641=
0
>>>>             Project: Harmony
>>>>          Issue Type: Bug
>>>>          Components: Classlib
>>>>            Reporter: juan wu
>>>>
>>>> When running the
>>>> testcase:org.apache.harmony.luni.tests.java.util.TimeZoneTest#test_get=
DSTSavings(),
>>>> on sun's jdk
>>>>         TimeZone st1 =3D TimeZone.getTimeZone("EST");
>>>>         assertEquals("T1A. Incorrect daylight savings returned",
>>>> ONE_HOUR, st1
>>>>                 .getDSTSavings());
>>>> this assertion failed, expect 36000, actually return 0.
>>>> and another
>>>> testcase:org.apache.harmony.luni.tests.java.util.TimeZoneTest#test_get=
DisplayNameZILjava_util_Locale(),
>>>> on sun's jdk
>>>>         TimeZone timezone =3D TimeZone.getTimeZone("Asia/Shanghai");
>>>>
>>>> assertEquals("\u683c\u6797\u5c3c\u6cbb\u6807\u51c6\u65f6\u95f4+0800",
>>>>                 timezone.getDisplayName(false, TimeZone.SHORT,
>>>> Locale.CHINA));
>>>> this assertion failed, expected was "=B8=F1=C1=D6=C4=E1=D6=CE=B1=EA=D7=
=BC=CA=B1=BC=E4+0800" but actually return
>>>> "CST".
>>>> while both testcases succeded in hamony's jdk.
>>>
>>> --
>>> This message is automatically generated by JIRA.
>>> -
>>> You can reply to this email to add a comment to the issue online.
>>>
>>>
>>
>>
>>
>
>
> --
> Best Regards,
> Regis.
>


--=20
Tony Wu
China Software Development Lab, IBM