harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Nathan Beyer <nbe...@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 18:05:12 GMT
2009/12/22 Ray Chen <clraychen@gmail.com>:
> Hi,
> Following simple test case can reproduce the problem:
>
> import java.util.TimeZone;
>
> public class TimeZoneTest {
>        public static void main(String[] args) {
>                TimeZone tz = TimeZone.getTimeZone("EST");
>
>                //harmony expected: 36000
>                //RI: 0
>                System.out.println("saving time="+tz.getDSTSavings());
>        }
> }

The short, three-letter IDs, are deprecated and are either mapped to
the olson names like "America/New_York" or left as is, which may be
out-of-date.

Again, what Sun JDK is being used? Has the olson data been updated?

>
> The EST TimeZone is initialed in TimeZone.getTimeZones line 42, it
> then calls the SimpleTimeZone's constructor. in the constructor I see:
>
>    public SimpleTimeZone(int offset, String name, int startMonth,
>            int startDay, int startDayOfWeek, int startTime, int endMonth,
>            int endDay, int endDayOfWeek, int endTime) {
>        this(offset, name, startMonth, startDay, startDayOfWeek, startTime,
>                endMonth, endDay, endDayOfWeek, endTime, 3600000);
>    }
>
> The dstSavings was set to 3600000.
>
> So maybe this issue is not related to TZ database or sth.
>
> 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.
>>
>
>
>
> --
> Regards,
>
> Ray Chen
>

Mime
View raw message