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 <nbe...@gmail.com> wrote:
> 2009/12/22 Ray Chen <clrayc...@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.re...@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)<j...@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
