You are viewing a plain text version of this content. The canonical link for it is here.
Posted to commits@harmony.apache.org by "juan wu (JIRA)" <ji...@apache.org> on 2009/12/21 08:02:18 UTC
[jira] Created: (HARMONY-6410) [classlib][luni] a bug found in
java.util.TimeZone#getDSTSavings()and
#getDisplayName(daylight,style,locale)
[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.
Re: [jira] Commented: (HARMONY-6410) [classlib][luni] a bug found in
java.util.TimeZone#getDSTSavings()and #getDisplayName(daylight,style,locale)
Posted by Ray Chen <cl...@gmail.com>.
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 <nb...@gmail.com> wrote:
> 2009/12/22 Ray Chen <cl...@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...@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)<ji...@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
Re: [jira] Commented: (HARMONY-6410) [classlib][luni] a bug found in
java.util.TimeZone#getDSTSavings()and #getDisplayName(daylight,style,locale)
Posted by Nathan Beyer <nb...@gmail.com>.
2009/12/22 Ray Chen <cl...@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...@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)<ji...@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
>
Re: [jira] Commented: (HARMONY-6410) [classlib][luni] a bug found in
java.util.TimeZone#getDSTSavings()and #getDisplayName(daylight,style,locale)
Posted by Ray Chen <cl...@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 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...@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)<ji...@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
Re: [jira] Commented: (HARMONY-6410) [classlib][luni] a bug found in
java.util.TimeZone#getDSTSavings()and #getDisplayName(daylight,style,locale)
Posted by Tony Wu <wu...@gmail.com>.
I think the Olson defines the time zone data rather than the localized
display name. both ICU and Jdk spec don't mention the detail of the
localized string.
but according to the spec of getDisplayName.
"Returns a name of this time zone suitable for presentation to the
user in the specified locale. If the display name is not available for
the locale, then this method returns a string in the normalized custom
ID format. "
I think ICU has gone further here.
On Tue, Dec 22, 2009 at 3:20 PM, Regis <xu...@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)<ji...@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.
>
--
Tony Wu
China Software Development Lab, IBM
Re: [jira] Commented: (HARMONY-6410) [classlib][luni] a bug found
in java.util.TimeZone#getDSTSavings()and #getDisplayName(daylight,style,locale)
Posted by Regis <xu...@gmail.com>.
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)<ji...@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.
Re: [jira] Commented: (HARMONY-6410) [classlib][luni] a bug found in
java.util.TimeZone#getDSTSavings()and #getDisplayName(daylight,style,locale)
Posted by Ray Chen <cl...@gmail.com>.
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.
On Tue, Dec 22, 2009 at 11:16 AM, Nathan Beyer (JIRA) <ji...@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.
>
>
--
Regards,
Ray Chen
[jira] Commented: (HARMONY-6410) [classlib][luni] a bug found in
java.util.TimeZone#getDSTSavings()and
#getDisplayName(daylight,style,locale)
Posted by "juan wu (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/HARMONY-6410?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12793552#action_12793552 ]
juan wu commented on HARMONY-6410:
----------------------------------
hi~
about the timezone info,I am not sure, following is the sun jdk version and harmony version info:
jre version of sun's jdk
C:\>java -version
java version "1.6.0"
Java(TM) SE Runtime Environment (build 1.6.0-b105)
Java HotSpot(TM) Client VM (build 1.6.0-b105, mixed mode)
harmony version
C:\trunk\deploy\jdk\jre\bin>java -version
Apache Harmony Launcher : (c) Copyright 1991, 2009 The Apache Software
Foundation or its licensors,
as applicable.
java version "1.6.0"
Harmony Virtual Machine Element (jvmwi3270-20090731_39920)
J9 (2.6)
IBM J9 2.6 Windows XP x86-32 (JIT enabled, AOT enabled)
J9VM - 20090731_039920
JIT - dev_20090710_1904
GC - R26_head_20090731_1122_B39896
J9CL - plugin
> [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.
[jira] Commented: (HARMONY-6410) [classlib][luni] a bug found in
java.util.TimeZone#getDSTSavings()and
#getDisplayName(daylight,style,locale)
Posted by "Nathan Beyer (JIRA)" <ji...@apache.org>.
[ 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.