harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Leo Li" <liyilei1...@gmail.com>
Subject Re: [classlib][sql]Is it RI's bug about java.sql.Timestamp.compareTo
Date Fri, 27 Oct 2006 05:12:37 GMT
Ya, I also recognized it. Harmony's java.util.Date is not the same as that
of java.sql.Timestamp, just following RI.


 I think if the toString result is reliable, the compareTo is false. I will
let the compareTo to follow toString since the latter gives detailed
information of the TimeStamp.


On 10/27/06, Andrew Zhang <zhanghuangzhu@gmail.com> wrote:
>
> Hi Leo,
>
> I think the problem is caused by negative value. java.util.Date and
> java.sql.Timestamp handles differently on negative value. Following code
> shows the difference:
>
> public static void main(String[] args) {
>        Long l1 = Long.MIN_VALUE;
>        Long l2 = Long.MIN_VALUE -1;
>
>        Timestamp timestamp1 = new Timestamp(l1);
>        Timestamp timestamp2 = new Timestamp(l2);
>        Date date1 = new Date(l1);
>        Date date2 = new Date(l2);
>        System.out.println(timestamp1);
>        System.out.println(timestamp2);
>        System.out.println(date1);
>        System.out.println(date2);
> }
> The output of RI is:
> 292278994-08-17 15:12:55.192
> 292278994-08-17 15:12:55.807
> Mon Dec 03 00:47:04 CST 292269055
> Sun Aug 17 15:12:55 CST 292278994
>
> Spec doesn't say how to handle negative value. (do i miss something here?)
>
> How would you like to fix this problem?
>
>
> On 10/27/06, Leo Li <liyilei1979@gmail.com> wrote:
> >
> > Hi, all:
> >     When fixing jira 1703,  I found that at an extreme situation,
> > TimeStamp.compareTo behaves differently from its semantic: the time it
> > represents:
> >     Here is the example:
> >
> >     public static void main(String[] args) {
> >        Long l1 = Long.MIN_VALUE;
> >        Long l2 = Long.MIN_VALUE -1;
> >
> >        Timestamp timestamp1 = new Timestamp(l1);
> >        Timestamp timestamp2 = new Timestamp(l2);
> >        System.out.println(timestamp1);
> >        System.out.println(timestamp2);
> >        System.out.println(timestamp1.compareTo(timestamp2));
> >    }
> >
> >    We get:
> >    292278994-08-17 15:12:55.192
> >    292278994-08-17 15:12:55.807
> >    1
> >
> >   From the times the timestamps represent, timestamp1 than timestamp2,
> > which indicate that timestamp1.compareTo(timestamp2) should be -1, while
> > the
> > actual result is 1, which indicate the reversed time sequence.
> >
> >   Furthermore, as the spec says java.sql.Timestamp wraps the
> > java.util.Date:"A thin wrapper around java.util.Date that allows the
> JDBC
> > API to identify this as an SQL TIMESTAMP value. It adds the ability to
> > hold
> > the SQL TIMESTAMP nanos value and provides formatting and parsing
> > operations
> > to support the JDBC escape syntax for timestamp values".
> >   I apply the same long value to java.util.Date:
> >        Long l1 = Long.MIN_VALUE;
> >        Long l2 = Long.MIN_VALUE -1;
> >
> >        Date date1 = new Date(l1);
> >        Date date2 = new Date(l2);
> >        System.out.println(date1.compareTo(date2));
> > I got -1, which indicate that date1 is earlier than date2 as we
> expected.
> > The samething happens on java.sql.Date.
> >
> > If no one objects, I will regard  it as RI's bug and go on with my
> patch.
> > --
> > Leo Li
> > China Software Development Lab, IBM
> >
> >
>
>
> --
> Best regards,
> Andrew Zhang
>
>


-- 
Leo Li
China Software Development Lab, IBM

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message