[threeten-dev] jdk bug in OffsetDateTime.INSTANT_COMPARATOR
Patrick Zhang
patrick.zhang at oracle.com
Sun May 19 21:38:20 PDT 2013
Hi Team,
It looks one bug in java.time.OffsetDateTime. The return value of
compareTo() and OffsetDateTime.INSTANT_COMPARATOR.compare() are different.
Sample code:
========
OffsetDateTime a = OffsetDateTime.of(2008, 6, 30, 11, 20, 40, 4,
ZoneOffset.ofHours(2));
OffsetDateTime b = OffsetDateTime.of(2008, 6, 30, 10, 20, 40, 5,
ZoneOffset.ofHours(1));
System.out.println(a.compareTo(b));
System.out.println(OffsetDateTime.INSTANT_COMPARATOR.compare(a, b));
========
Output:
========
-1
1
========
I do not think it makes sense. The correct value should be a<b.
And it looks the implementation of INSTANT_COMPARATOR is incorrect:
=========
public static final Comparator<OffsetDateTime> INSTANT_COMPARATOR =
new Comparator<OffsetDateTime>() {
@Override
public int compare(OffsetDateTime datetime1, OffsetDateTime
datetime2) {
int cmp = Long.compare(datetime1.toEpochSecond(),
datetime2.toEpochSecond());
if (cmp == 0) {
cmp =
Long.compare(datetime1.toLocalTime().toNanoOfDay(),
datetime2.toLocalTime().toNanoOfDay());
}
return cmp;
}
};
=========
I think we can not compare localTime part of OffsetDateTime directly.
It should be convert to Instant firstly. Then compare epochSecond and
nanoOfSecond.....
Regards
Patrick
More information about the threeten-dev
mailing list