OPERATING SYSTEM
----------------
All

FULL JDK VERSION
----------------
All 5.0, 6, and 7
Not reproducible with 1.4.2

PROBLEM DESCRIPTION
-------------------
When a java.sql.Timestamp object is constructed with an extremely low millisecond value (via the java.sql.Timestamp(long time) constructor), running the java.sql.Timestamp.compareTo() method, before(), after(), to compare the timestamp with another java.sql.Timestamp instance yields an incorrect results.

The same extremely low values can be compared succesfully using the java.sql.Date and java.util.Date classes directly.

TESTCASE
--------
There are two testcases attached to this report.

1) TimestampTestBasic.java - A basic "pass/fail" which uses only java.sql.Timestamp.
2) TimestampTestVerbose.java - A verbose version which dumps Timestamp values
    to System.out, including java.util.Date, java.sql.Date.

In both testcases, the minimum compare value is constructed using Long.MIN_VALUE
and the maximum is set to 0L. compareTo() should return -1, but returns 1 using
java.sql.Timestamp.compareTo().

  Ie.,
  java.sql.Timestamp compare result = 1
  java.util.Date compare result = -1
  java.sql.Date compare result = -1

NOTE:
-----
It is worth noting that when 808 is added to the Long.MIN_VALUE (-2^63 +808) the java.sql.Timestamp.compareTo() method
returns the Correct value. 5808 also returns correctly. Interestingly, adding 807 and 809 to Long.MIN_VALUE return the
incorrect value (1) using java.sql.Timestamp.compareTo().This suggests, possibly, that nanosecond rounding needs to be explored.

Long.MIN_VALUE (-2^63 +808) = -9223372036854775000
Long.MIN_VALUE (-2^63) = -9223372036854775808


WORKAROUND
----------
None know, apart from avoiding use of such an extremely low time value.