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,
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
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;
Timesta
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;
