[threeten-dev] jdk bug in OffsetDateTime.INSTANT_COMPARATOR
Patrick Zhang
patrick.zhang at oracle.com
Mon May 20 19:21:00 PDT 2013
Hi Roger,
I have submitted https://jbs.oracle.com/bugs/browse/JDK-8014939 for it.
Regards
Patrick
On 5/20/13 12:38 PM, Patrick Zhang wrote:
> 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