harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Tony Wu <wuyue...@gmail.com>
Subject Re: [jira] Commented: (HARMONY-6410) [classlib][luni] a bug found in java.util.TimeZone#getDSTSavings()and #getDisplayName(daylight,style,locale)
Date Tue, 22 Dec 2009 07:57:01 GMT
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 uses
> "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=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12793477#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 zone
>>> 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-6410
>>>>             Project: Harmony
>>>>          Issue Type: Bug
>>>>          Components: Classlib
>>>>            Reporter: juan wu
>>>>
>>>> When running the
>>>> testcase:org.apache.harmony.luni.tests.java.util.TimeZoneTest#test_getDSTSavings(),
>>>> on sun's jdk
>>>>         TimeZone st1 = 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_getDisplayNameZILjava_util_Locale(),
>>>> on sun's jdk
>>>>         TimeZone timezone = 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 "格林尼治标准时间+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.
>



-- 
Tony Wu
China Software Development Lab, IBM

Mime
View raw message