harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Leo Li" <liyilei1...@gmail.com>
Subject [classlib][sql]Is it RI's bug about java.sql.Timestamp.compareTo
Date Fri, 27 Oct 2006 02:18:44 GMT
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

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