Mailing-List: contact harmony-dev-help@incubator.apache.org; run by ezmlm
Precedence: bulk
Reply-To: harmony-dev@incubator.apache.org
Received-SPF: pass (herse.apache.org: domain of alexei.zakharov@gmail.com
 designates 66.249.92.168 as permitted sender)
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws;
        s=beta; d=gmail.com;
        h=received:message-id:date:from:to:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references;
        b=hVMRLNObF7ZtTSuvmZELgqOMFWGVoLfWs96vRdm5QAKS0/I6EAFXuA9pgls9AmxNAMQZ5yNmzfgUaS18xXg3Mhc6cZXrnu9MdzsPT5Rw9NYTYe85zv+T+P/F+fWc+jBa2jlCMSi0YmcFo/5vgVZNXnkHbDbxtFZ2r2SU8pw47+8=
Message-ID: <2c9597b90610270513q1dd55c56u7fe782ffd3ab8401@mail.gmail.com>
Date: Fri, 27 Oct 2006 16:13:31 +0400
From: "Alexei Zakharov" <alexei.zakharov@gmail.com>
To: harmony-dev@incubator.apache.org
Subject: Re: [classlib][sql]Is it RI's bug about java.sql.Timestamp.compareTo
In-Reply-To: <e66844de0610262212m343f271u8475df153f8f7115@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
References: <e66844de0610261918k55b55b18i3b6e86b232bfedb3@mail.gmail.com>
	 <4d0b24970610262206i62ef0e44s98e2934fae529472@mail.gmail.com>
	 <e66844de0610262212m343f271u8475df153f8f7115@mail.gmail.com>

Hi all,

I agree that RI's Timestamp#compareTo() is buggy. The #toString()
method seems to be working ok but it would be nice if it can output
something like BC and AD since now the output is a bit confusing. I am
not persuading you to do so, just reflecting upon the subject.

Thanks,

2006/10/27, Leo Li <liyilei1979@gmail.com>:
> 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.

-- 
Alexei Zakharov,
Intel Enterprise Solutions Software Division