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

Reply via email to