harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ray Chen <clrayc...@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:53:51 GMT
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 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