You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@harmony.apache.org by Leo Li <li...@gmail.com> on 2006/10/27 04:18:44 UTC
[classlib][sql]Is it RI's bug about java.sql.Timestamp.compareTo
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
Re: [classlib][sql]Is it RI's bug about java.sql.Timestamp.compareTo
Posted by Alexei Zakharov <al...@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 <li...@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 <zh...@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 <li...@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
Re: [classlib][sql]Is it RI's bug about java.sql.Timestamp.compareTo
Posted by Leo Li <li...@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 <zh...@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 <li...@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
Re: [classlib][sql]Is it RI's bug about java.sql.Timestamp.compareTo
Posted by Andrew Zhang <zh...@gmail.com>.
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 <li...@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