Re: [classlib][util] java.util.Date.toString output is inconsistent with RI

[Tony Wu <wu...@gmail.com>]

Well. I was testing on JDK 1.5, seems this behavior has been changed in 6.0.

Also as Nathan pointed out that the behavior of toString is not
guaranteed to be time zone related. I inclined to follow RI6 here.
Patch has been committed at r690853, please verify.

On Sat, Aug 30, 2008 at 10:29 AM, Nathan Beyer <nd...@apache.org> wrote:
> Note - the toString format does mention that the time zone may change
> to reflect daylight-savings-time, which is the difference between MDT
> and MST. What's the actual time being tested? Is it within
> daylight-savings?
>
> In any case, I would consider this a non-bug difference, as the format
> is correct, it's just the locale/time zone data that varies, which is
> in the realm of acceptable differences.
>
> -Nathan
>
> On Thu, Aug 28, 2008 at 10:21 PM, Tony Wu <wu...@gmail.com> wrote:
>> I run the testcase and found that it failed on RI. can you tell us why
>> RI returns MDT rather than MST even if we explicitly set the default
>> timezone to MST? Is it a non-bug difference?
>> And please reset the default timezone to the original one after
>> running your testcase otherwise it may have side effect to other
>> tests.
>>
>> On Wed, Aug 27, 2008 at 6:04 PM, Jim Yu <ju...@gmail.com> wrote:
>>> Good idea. I've revised my patch and attached it to the JIRA again. Thanks,
>>> Alexey.
>>>
>>> 2008/8/27 Alexey Petrenko <al...@gmail.com>
>>>
>>>> I would suggest to change toDayOfWeek and toMonth methods to simple
>>>> static arrays. We do not need these calls and switches in this case.
>>>>
>>>> Thanks in advance.
>>>>
>>>> SY, Alexey
>>>>
>>>> 2008/8/27 Jim Yu <ju...@gmail.com>:
>>>> > Hi all,
>>>> >
>>>> > I took a look at [1] and found that we can remove the delegation to
>>>> > SimpleDateFormat since we only use the en-us locale here.
>>>> > I think we can easily implement this method instead of delegating to
>>>> > SimpleDateFormat. Then, this defect can be easily resolved.
>>>> > Moreover, invoking SimpleDateFormat will lead to low performance of this
>>>> > API. For a simple testcase as below [2], the original
>>>> > result is 119667 millisecs while the result after applying my patch is
>>>> only
>>>> > 1140 millisecs. I've attached my patch to this JIRA.
>>>> > Is there anyone to verify the patch? Thanks.
>>>> >
>>>> > [1] https://issues.apache.org/jira/browse/HARMONY-5468
>>>> > [2]
>>>> > import java.util.Date;
>>>> >
>>>> > public class DateToStringTest {
>>>> >
>>>> >    public static void main(String[] args) {
>>>> >        long start = System.currentTimeMillis();
>>>> >        Date date = new Date();
>>>> >        long count = 100000;
>>>> >        System.out.println(date.toString());
>>>> >        while(--count != 0) {
>>>> >              date.toString();
>>>> >        }
>>>> >        System.out.println(System.currentTimeMillis() - start);
>>>> >    }
>>>> > }
>>>> > --
>>>> > Best Regards,
>>>> > Jim, Jun Jie Yu
>>>> >
>>>> > China Software Development Lab, IBM
>>>> >
>>>>
>>>
>>>
>>>
>>> --
>>> Best Regards,
>>> Jim, Jun Jie Yu
>>>
>>> China Software Development Lab, IBM
>>>
>>
>>
>>
>> --
>> Tony Wu
>> China Software Development Lab, IBM
>>
>



-- 
Tony Wu
China Software Development Lab, IBM

Re: [classlib][util] java.util.Date.toString output is inconsistent with RI

[Jim Yu <ju...@gmail.com>]

Verified at r690853. Thanks, Tony.

2008/9/1 Tony Wu <wu...@gmail.com>

> Well. I was testing on JDK 1.5, seems this behavior has been changed in
> 6.0.
>
> Also as Nathan pointed out that the behavior of toString is not
> guaranteed to be time zone related. I inclined to follow RI6 here.
> Patch has been committed at r690853, please verify.
>
> On Sat, Aug 30, 2008 at 10:29 AM, Nathan Beyer <nd...@apache.org> wrote:
> > Note - the toString format does mention that the time zone may change
> > to reflect daylight-savings-time, which is the difference between MDT
> > and MST. What's the actual time being tested? Is it within
> > daylight-savings?
> >
> > In any case, I would consider this a non-bug difference, as the format
> > is correct, it's just the locale/time zone data that varies, which is
> > in the realm of acceptable differences.
> >
> > -Nathan
> >
> > On Thu, Aug 28, 2008 at 10:21 PM, Tony Wu <wu...@gmail.com> wrote:
> >> I run the testcase and found that it failed on RI. can you tell us why
> >> RI returns MDT rather than MST even if we explicitly set the default
> >> timezone to MST? Is it a non-bug difference?
> >> And please reset the default timezone to the original one after
> >> running your testcase otherwise it may have side effect to other
> >> tests.
> >>
> >> On Wed, Aug 27, 2008 at 6:04 PM, Jim Yu <ju...@gmail.com> wrote:
> >>> Good idea. I've revised my patch and attached it to the JIRA again.
> Thanks,
> >>> Alexey.
> >>>
> >>> 2008/8/27 Alexey Petrenko <al...@gmail.com>
> >>>
> >>>> I would suggest to change toDayOfWeek and toMonth methods to simple
> >>>> static arrays. We do not need these calls and switches in this case.
> >>>>
> >>>> Thanks in advance.
> >>>>
> >>>> SY, Alexey
> >>>>
> >>>> 2008/8/27 Jim Yu <ju...@gmail.com>:
> >>>> > Hi all,
> >>>> >
> >>>> > I took a look at [1] and found that we can remove the delegation to
> >>>> > SimpleDateFormat since we only use the en-us locale here.
> >>>> > I think we can easily implement this method instead of delegating to
> >>>> > SimpleDateFormat. Then, this defect can be easily resolved.
> >>>> > Moreover, invoking SimpleDateFormat will lead to low performance of
> this
> >>>> > API. For a simple testcase as below [2], the original
> >>>> > result is 119667 millisecs while the result after applying my patch
> is
> >>>> only
> >>>> > 1140 millisecs. I've attached my patch to this JIRA.
> >>>> > Is there anyone to verify the patch? Thanks.
> >>>> >
> >>>> > [1] https://issues.apache.org/jira/browse/HARMONY-5468
> >>>> > [2]
> >>>> > import java.util.Date;
> >>>> >
> >>>> > public class DateToStringTest {
> >>>> >
> >>>> >    public static void main(String[] args) {
> >>>> >        long start = System.currentTimeMillis();
> >>>> >        Date date = new Date();
> >>>> >        long count = 100000;
> >>>> >        System.out.println(date.toString());
> >>>> >        while(--count != 0) {
> >>>> >              date.toString();
> >>>> >        }
> >>>> >        System.out.println(System.currentTimeMillis() - start);
> >>>> >    }
> >>>> > }
> >>>> > --
> >>>> > Best Regards,
> >>>> > Jim, Jun Jie Yu
> >>>> >
> >>>> > China Software Development Lab, IBM
> >>>> >
> >>>>
> >>>
> >>>
> >>>
> >>> --
> >>> Best Regards,
> >>> Jim, Jun Jie Yu
> >>>
> >>> China Software Development Lab, IBM
> >>>
> >>
> >>
> >>
> >> --
> >> Tony Wu
> >> China Software Development Lab, IBM
> >>
> >
>
>
>
> --
> Tony Wu
> China Software Development Lab, IBM
>



-- 
Best Regards,
Jim, Jun Jie Yu

China Software Development Lab, IBM