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.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
