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 Wed, 23 Dec 2009 01:47:15 GMT
Hi,
I think wu juan has given out the JDK version,  and for me the java
version is following:

java version "1.6.0_14"
Java(TM) SE Runtime Environment (build 1.6.0_14-b08)
Java HotSpot(TM) Client VM (build 14.0-b16, mixed mode, sharing)

I am not sure if the olson data been updated, I will check it out.

On Wed, Dec 23, 2009 at 2:05 AM, Nathan Beyer <nbeyer@gmail.com> wrote:
> 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
>>
>



-- 
Regards,

Ray Chen

Mime
View raw message