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 <[EMAIL PROTECTED]> 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 <[EMAIL PROTECTED]> 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