Verified at r690853. Thanks, Tony. 2008/9/1 Tony Wu <[EMAIL PROTECTED]>
> 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 <[EMAIL PROTECTED]> 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 <[EMAIL PROTECTED]> 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 <[EMAIL PROTECTED]> wrote: > >>> Good idea. I've revised my patch and attached it to the JIRA again. > Thanks, > >>> Alexey. > >>> > >>> 2008/8/27 Alexey Petrenko <[EMAIL PROTECTED]> > >>> > >>>> 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 <[EMAIL PROTECTED]>: > >>>> > 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
